* netperf and endianness
From: David Miller @ 2012-06-08 1:09 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
Rick, I tried to use netperf between my x86-64 and sparc64 systems and
nothing works.
Does netperf do it's messaging in cpu byte order only?
I don't see anything in netperf-2.5.x that translates into and out of
network byte order :-/
^ permalink raw reply
* [PATCH] e1000e: disable rxhash when try to enable jumbo frame also rxhash and rxcsum have enabled
From: Joe Jin @ 2012-06-08 1:06 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, Guru Anbalagane, Adnan Misherfi, David S. Miller
Cc: e1000-devel, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Upstream commit 70495a5 check if both rxhash and rxcsum enabled when enabling
jumbo frames and disallowed all of them enabled at the same time.
Since jumbo frame widely be used in real world, so when try to enable jumbo
frames but rxhash and rxcsum have enabled, change the default behavior to
disable receive hashing.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi@oracle.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index a4b0435..b9f0857 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -66,6 +66,8 @@ module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
static void e1000e_disable_aspm(struct pci_dev *pdev, u16 state);
+static int e1000_set_features(struct net_device *netdev,
+ netdev_features_t features);
static const struct e1000_info *e1000_info_tbl[] = {
[board_82571] = &e1000_82571_info,
@@ -5254,8 +5256,15 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
*/
if ((netdev->features & NETIF_F_RXCSUM) &&
(netdev->features & NETIF_F_RXHASH)) {
- e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
- return -EINVAL;
+ netdev_features_t features;
+
+ /* Disable receive hashing if conflicted */
+ features = netdev->features & (~NETIF_F_RXHASH);
+ if (e1000_set_features(netdev, features)) {
+ e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
+ return -EINVAL;
+ }
+ e_info("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disabling Receive Hashing.\n");
}
}
--
1.7.10.2
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32
From: Josh Boyer @ 2012-06-08 1:04 UTC (permalink / raw)
To: Mark Brown
Cc: Ben Hutchings, Lennert Buytenhek, Andrew Lunn, Olof Johansson,
netdev
In-Reply-To: <20120608003445.GC21150@sirena.org.uk>
On Fri, Jun 08, 2012 at 01:34:45AM +0100, Mark Brown wrote:
> On Thu, Jun 07, 2012 at 07:55:51PM -0400, Josh Boyer wrote:
> > On Fri, Jun 08, 2012 at 12:51:15AM +0100, Mark Brown wrote:
>
> > > This sort of issue is just the tip of the iceberg in terms of what it's
> > > useful to do with the API.
>
> > Yes, sounds like it. All I ask is that people test their patches along
> > the way so things don't get broken. I mean, it's great we have an
> > iceberg but I don't want tons of drivers on other architectures running
> > into the thing and sinking because people aren't being careful. Except
> > maybe the one already appropriately (nick)named.
>
> It's really hard to blame the submitters here - this really isn't the
> sort of API that you'd expect to only be available conditionally so this
> isn't something that one would expect to have to worry about. It's a
> product of the age of the clock API and the glacial progress on the
> generic clock API.
I'm not placing blame. I'm declaring people should be cautious going
forward. 5 arches have the clock API. 21 don't. Whatever reasons
there are for that, I don't care. It should be a big warning sign.
It might even be beneficial to put some Kconfig dependencies on both
CONFIG_COMMON_CLK (which is somewhat misleadingly named) and
CONFIG_CLKDEV_LOOKUP so those are only selectable on those 5 arches.
Something like:
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 4864407..3f49c22 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -1,6 +1,7 @@
config CLKDEV_LOOKUP
bool
+ depends on (ARM || SUPERH || MIPS || C6X || BLACKFIN)
select HAVE_CLK
config HAVE_CLK_PREPARE
@@ -11,6 +12,7 @@ config HAVE_MACH_CLKDEV
config COMMON_CLK
bool
+ depends on (ARM || SUPERH || MIPS || C6X || BLACKFIN)
select HAVE_CLK_PREPARE
select CLKDEV_LOOKUP
---help---
Regardless, hopefully things like this will get hit in linux-next in the
future. I believe the only reason that it wasn't this time is that
none of the PPC defconfigs build in linux-next bother to build the
driver at all.
josh
^ permalink raw reply related
* Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32
From: Mark Brown @ 2012-06-08 0:34 UTC (permalink / raw)
To: Josh Boyer
Cc: Ben Hutchings, Lennert Buytenhek, Andrew Lunn, Olof Johansson,
netdev
In-Reply-To: <20120607235550.GK7683@zod.bos.redhat.com>
On Thu, Jun 07, 2012 at 07:55:51PM -0400, Josh Boyer wrote:
> On Fri, Jun 08, 2012 at 12:51:15AM +0100, Mark Brown wrote:
> > This sort of issue is just the tip of the iceberg in terms of what it's
> > useful to do with the API.
> Yes, sounds like it. All I ask is that people test their patches along
> the way so things don't get broken. I mean, it's great we have an
> iceberg but I don't want tons of drivers on other architectures running
> into the thing and sinking because people aren't being careful. Except
> maybe the one already appropriately (nick)named.
It's really hard to blame the submitters here - this really isn't the
sort of API that you'd expect to only be available conditionally so this
isn't something that one would expect to have to worry about. It's a
product of the age of the clock API and the glacial progress on the
generic clock API.
^ permalink raw reply
* Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32
From: Josh Boyer @ 2012-06-07 23:55 UTC (permalink / raw)
To: Mark Brown
Cc: Ben Hutchings, Lennert Buytenhek, Andrew Lunn, Olof Johansson,
netdev
In-Reply-To: <20120607235115.GB21150@sirena.org.uk>
On Fri, Jun 08, 2012 at 12:51:15AM +0100, Mark Brown wrote:
> On Tue, Jun 05, 2012 at 10:38:42PM -0400, Josh Boyer wrote:
>
> > 1) revert the change for ARM that introduced th clk stuff
> > 2) do a similar change as the original commit but with a bunch of
> > #ifdef-ery
> > 3) implement the clkdev API stuff for 32-bit ppc
>
> > Honestly, I'd go for either 1 or 2. The commit that introduced it was
> > broken to begin with, but that isn't my call.
>
> There's a change going in which stubs out the clock API when not used
> which should resolve the immediate issue, though really the best thing
> here is just to enable use of the generic clock API if the platform
> doesn't have one of its own - it's not just platforms that need clocks
> so we really want to get that rolled out as widely as possible.
Sounds great. I have no objections with any of those plans.
> This sort of issue is just the tip of the iceberg in terms of what it's
> useful to do with the API.
Yes, sounds like it. All I ask is that people test their patches along
the way so things don't get broken. I mean, it's great we have an
iceberg but I don't want tons of drivers on other architectures running
into the thing and sinking because people aren't being careful. Except
maybe the one already appropriately (nick)named.
josh
^ permalink raw reply
* Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32
From: Mark Brown @ 2012-06-07 23:51 UTC (permalink / raw)
To: Josh Boyer
Cc: Ben Hutchings, Lennert Buytenhek, Andrew Lunn, Olof Johansson,
netdev
In-Reply-To: <20120606023842.GD7683@zod.bos.redhat.com>
On Tue, Jun 05, 2012 at 10:38:42PM -0400, Josh Boyer wrote:
> 1) revert the change for ARM that introduced th clk stuff
> 2) do a similar change as the original commit but with a bunch of
> #ifdef-ery
> 3) implement the clkdev API stuff for 32-bit ppc
> Honestly, I'd go for either 1 or 2. The commit that introduced it was
> broken to begin with, but that isn't my call.
There's a change going in which stubs out the clock API when not used
which should resolve the immediate issue, though really the best thing
here is just to enable use of the generic clock API if the platform
doesn't have one of its own - it's not just platforms that need clocks
so we really want to get that rolled out as widely as possible.
This sort of issue is just the tip of the iceberg in terms of what it's
useful to do with the API.
^ permalink raw reply
* Re: tg3: transmit timed out, resetting
From: Matt Carlson @ 2012-06-07 22:56 UTC (permalink / raw)
To: ethan zhao; +Cc: Eric Dumazet, Matt Carlson, Christian Kujau, LKML, netdev
In-Reply-To: <CABawtvOBJQ-oajFQmviOdgKCub-4n06kRW+x7nE2uyiWnoky9Q@mail.gmail.com>
On Wed, Jun 06, 2012 at 12:52:32PM +0800, ethan zhao wrote:
> Eric,
> That is ask for confirmation from Matt Carlson of Broadcom.
>
> Ethan
>
> On Wed, Jun 6, 2012 at 12:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Wed, 2012-06-06 at 10:29 +0800, ethan zhao wrote:
> >> So no way to fix it via firmware update or Linux driver ? :<
> >
> > Yes, but you need to cooperate, or else it might take more time than
> > necessary.
> >
> > Asking questions like that on lkml is not going to help very much.
> >
> > So, once again, we kindly ask you try a recent kernel and post
> > register dump and some additional information when transmit timeouts
> > happen.
> >
> > The 'latest kernel' is either linux-3.5.rc1, or one of David Miller
> > tree :
> >
> > http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=summary
> >
> > or
> >
> > http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=summary
> >
> > Thanks
Does the following patch fix your problem?
[PATCH] tg3: Apply short DMA frag workaround to 5906
5906 devices also need the short DMA fragment workaround. This patch
makes the necessary change.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index d55df32..2db4d70 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14275,7 +14275,8 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
}
}
- if (tg3_flag(tp, 5755_PLUS))
+ if (tg3_flag(tp, 5755_PLUS) ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
tg3_flag_set(tp, SHORT_DMA_BUG);
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719)
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checks
From: Phil Dibowitz @ 2012-06-07 22:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev, phild
In-Reply-To: <20120607.145312.1150524706209064440.davem@davemloft.net>
On Thu, Jun 07, 2012 at 02:53:12PM -0700, David Miller wrote:
> From: Phil Dibowitz <phil@ipom.com>
> Date: Tue, 5 Jun 2012 08:40:58 -0700
>
> > and I want to make sure it makes it upstream by World v6 Launch Day.
>
> Submitting a patch just a day or two beforehand is absolutely not the
> way to achieve this.
My wording was poor. I didn't expect it to be in the kernel, I just wanted to
at least get it out the door by then.
--
Phil Dibowitz phil@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Be who you are and say what you feel, because those who mind don't matter
and those who matter don't mind."
- Dr. Seuss
^ permalink raw reply
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Francois Romieu @ 2012-06-07 22:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Denys Fedoryshchenko, davem, netdev, linux-kernel
In-Reply-To: <1339104606.6001.4.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> :
[...]
> If LLTX is used, this means several cpus can execute this code at the
> same time.
>
> You need percpu stats, or use atomic primitives.
Would adding percpu stats not be frown upon ?
As atomic will defeat the 64 bits stats on 32 bits, I should probably stick
to plain bh disabling lock.
--
Ueimor
^ permalink raw reply
* [PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8
From: Thomas Graf @ 2012-06-07 22:33 UTC (permalink / raw)
To: davem; +Cc: netdev
Routing of 127/8 is tradtionally forbidden, we consider
packets from that address block martian when routing and do
not process corresponding ARP requests.
This is a sane default but renders a huge address space
practically unuseable.
The RFC states that no address within the 127/8 block should
ever appear on any network anywhere but it does not forbid
the use of such addresses outside of the loopback device in
particular. For example to address a pool of virtual guests
behind a load balancer.
This patch adds a new interface option 'route_localnet'
enabling routing of the 127/8 address block and processing
of ARP requests on a specific interface.
Note that for the feature to work, the default local route
covering 127/8 dev lo needs to be removed.
Example:
$ sysctl -w net.ipv4.conf.eth0.route_localnet=1
$ ip route del 127.0.0.0/8 dev lo table local
$ ip addr add 127.1.0.1/16 dev eth0
$ ip route flush cache
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
Documentation/networking/ip-sysctl.txt | 5 +++++
include/linux/inetdevice.h | 2 ++
net/ipv4/arp.c | 3 ++-
net/ipv4/devinet.c | 5 ++++-
net/ipv4/route.c | 30 +++++++++++++++++++++---------
5 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 6f896b9..99d0e05 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -862,6 +862,11 @@ accept_local - BOOLEAN
local interfaces over the wire and have them accepted properly.
default FALSE
+route_localnet - BOOLEAN
+ Do not consider loopback addresses as martian source or destination
+ while routing. This enables the use of 127/8 for local routing purposes.
+ default FALSE
+
rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 597f4a9..67f9dda 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -38,6 +38,7 @@ enum
IPV4_DEVCONF_ACCEPT_LOCAL,
IPV4_DEVCONF_SRC_VMARK,
IPV4_DEVCONF_PROXY_ARP_PVLAN,
+ IPV4_DEVCONF_ROUTE_LOCALNET,
__IPV4_DEVCONF_MAX
};
@@ -131,6 +132,7 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
#define IN_DEV_PROMOTE_SECONDARIES(in_dev) \
IN_DEV_ORCONF((in_dev), \
PROMOTE_SECONDARIES)
+#define IN_DEV_ROUTE_LOCALNET(in_dev) IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
#define IN_DEV_RX_REDIRECTS(in_dev) \
((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index cda37be..2e560f0 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -790,7 +790,8 @@ static int arp_process(struct sk_buff *skb)
* Check for bad requests for 127.x.x.x and requests for multicast
* addresses. If this is one such, delete it.
*/
- if (ipv4_is_loopback(tip) || ipv4_is_multicast(tip))
+ if (ipv4_is_multicast(tip) ||
+ (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
goto out;
/*
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 10e15a1..378c28b 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1500,7 +1500,8 @@ static int devinet_conf_proc(ctl_table *ctl, int write,
if (cnf == net->ipv4.devconf_dflt)
devinet_copy_dflt_conf(net, i);
- if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1)
+ if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||
+ i == IPV4_DEVCONF_ROUTE_LOCALNET)
if ((new_value == 0) && (old_value != 0))
rt_cache_flush(net, 0);
}
@@ -1617,6 +1618,8 @@ static struct devinet_sysctl_table {
"force_igmp_version"),
DEVINET_SYSCTL_FLUSHING_ENTRY(PROMOTE_SECONDARIES,
"promote_secondaries"),
+ DEVINET_SYSCTL_FLUSHING_ENTRY(ROUTE_LOCALNET,
+ "route_localnet"),
},
};
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 98b30d0..7509acc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2023,9 +2023,13 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
return -EINVAL;
if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
- ipv4_is_loopback(saddr) || skb->protocol != htons(ETH_P_IP))
+ skb->protocol != htons(ETH_P_IP))
goto e_inval;
+ if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+ if (ipv4_is_loopback(saddr))
+ goto e_inval;
+
if (ipv4_is_zeronet(saddr)) {
if (!ipv4_is_local_multicast(daddr))
goto e_inval;
@@ -2266,8 +2270,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
by fib_lookup.
*/
- if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
- ipv4_is_loopback(saddr))
+ if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr))
goto martian_source;
if (ipv4_is_lbcast(daddr) || (saddr == 0 && daddr == 0))
@@ -2279,9 +2282,17 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(saddr))
goto martian_source;
- if (ipv4_is_zeronet(daddr) || ipv4_is_loopback(daddr))
+ if (ipv4_is_zeronet(daddr))
goto martian_destination;
+ if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
+ if (ipv4_is_loopback(daddr))
+ goto martian_destination;
+
+ if (ipv4_is_loopback(saddr))
+ goto martian_source;
+ }
+
/*
* Now we are ready to route packet.
*/
@@ -2520,9 +2531,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
u16 type = res->type;
struct rtable *rth;
- if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+ in_dev = __in_dev_get_rcu(dev_out);
+ if (!in_dev)
return ERR_PTR(-EINVAL);
+ if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+ if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+ return ERR_PTR(-EINVAL);
+
if (ipv4_is_lbcast(fl4->daddr))
type = RTN_BROADCAST;
else if (ipv4_is_multicast(fl4->daddr))
@@ -2533,10 +2549,6 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
if (dev_out->flags & IFF_LOOPBACK)
flags |= RTCF_LOCAL;
- in_dev = __in_dev_get_rcu(dev_out);
- if (!in_dev)
- return ERR_PTR(-EINVAL);
-
if (type == RTN_BROADCAST) {
flags |= RTCF_BROADCAST | RTCF_LOCAL;
fi = NULL;
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] fix kernel crash in the macvlan driver
From: Eric W. Biederman @ 2012-06-07 22:24 UTC (permalink / raw)
To: Ani Sinha; +Cc: netdev, Francesco Ruggeri
In-Reply-To: <alpine.OSX.2.00.1206071320040.86561@animac.local>
Ani Sinha <ani@aristanetworks.com> writes:
> Hi Eric :
>
> On Thu, 7 Jun 2012, Eric W. Biederman wrote:
>
>> I don't completely follow the logic of your change. Crashing in
>> macvlan_addr_busy does seem to indicate you are using a corrupted data
>> structure.
>
> The logic of my change is as follows :
>
> As far as I can see, macvlan_newlink() pairs with macvlan_dellink(). If
> you are incrementing the reference count in newlink(), the corresponding
> decrement should be, in my opinion in dellink(). If you are derementing
> the count in uninit(), you are asuming that for every dellink() call,
> there is a corresponding uninit() call. I am not sure if this assumption
> is correct. Perhaps you can shed some more lights on this.
Yes. Look at net/core/dev.c
dellink calls unregister_netdevice_queue.
The active part of unregister_netdevice_queue rollback_registered_many
calls dev->ndo_stop() and then ndo_uninit.
We might still be using rcu hash lookups until ndo_close is called and
so we really don't want to move the decrement before then.
>> My compiled version of macvlan_addr_busy is much smaller than yours so I
>> can't guess based on your disassembly what is wrong. But by reading the
>> code it must either be port->dev->dev_addr or the rcu
>> macvlan_hash_lookup.
>
> Yes, the corruption is in port->dev->dev_addr. The dev_addr seems to get a
> bogus address value.
Interesting if it is port->dev->dev_addr than count is really out of the
picture.
My blind guess would be that port->dev is getting freed and recycled
before dev_addr gets accessed. But macvlan_device_event seems to
prevent that.
>> I might just be dense today but I can't possibly see how moving that
>> decrement would solve the crash you have reported below.
>
> In my tests, I have confirmed that with my change, the crash I reported is
> no longer reproducable with our scripts. I have also verified that when I
> pull out your d5cd92448fded change, I can also no longer reproduce the
> issue. So I believe that the crash is related to the above change.
> However, I am not very familier with the code in the macvlan
> driver, so I can not say for sure that the fix I made genuinely solves the
> problem.
It sounds to me like you have a memory stomp and that recompiling the
code winds up changing what gets stomped.
Eric
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Michael S. Tsirkin @ 2012-06-07 22:19 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20120606075217.29081.30713.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Wed, Jun 06, 2012 at 03:52:17PM +0800, Jason Wang wrote:
> Satistics counters is useful for debugging and performance optimization, so this
> patch lets virtio_net driver collect following and export them to userspace
> through "ethtool -S":
>
> - number of packets sent/received
> - number of bytes sent/received
> - number of callbacks for tx/rx
> - number of kick for tx/rx
> - number of bytes/packets queued for tx
>
> As virtnet_stats were per-cpu, so both per-cpu and gloabl satistics were
> collected like:
>
> NIC statistics:
> tx_bytes[0]: 1731209929
> tx_packets[0]: 60685
> tx_kicks[0]: 63
> tx_callbacks[0]: 73
> tx_queued_bytes[0]: 1935749360
> tx_queued_packets[0]: 80652
> rx_bytes[0]: 2695648
> rx_packets[0]: 40767
> rx_kicks[0]: 1
> rx_callbacks[0]: 2077
> tx_bytes[1]: 9105588697
> tx_packets[1]: 344150
> tx_kicks[1]: 162
> tx_callbacks[1]: 905
> tx_queued_bytes[1]: 8901049412
> tx_queued_packets[1]: 324184
> rx_bytes[1]: 23679828
> rx_packets[1]: 358770
> rx_kicks[1]: 6
> rx_callbacks[1]: 17717
> tx_bytes: 10836798626
> tx_packets: 404835
> tx_kicks: 225
> tx_callbacks: 978
> tx_queued_bytes: 10836798772
> tx_queued_packets: 404836
> rx_bytes: 26375476
> rx_packets: 399537
> rx_kicks: 7
> rx_callbacks: 19794
>
> TODO:
>
> - more statistics
> - calculate the pending bytes/pkts
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> ---
> Changes from v1:
>
> - style & typo fixs
> - convert the statistics fields to array
> - use unlikely()
> ---
> drivers/net/virtio_net.c | 115 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 113 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 6e4aa6f..909a0a7 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -44,8 +44,14 @@ module_param(gso, bool, 0444);
> enum virtnet_stats_type {
> VIRTNET_TX_BYTES,
> VIRTNET_TX_PACKETS,
> + VIRTNET_TX_KICKS,
> + VIRTNET_TX_CBS,
> + VIRTNET_TX_Q_BYTES,
> + VIRTNET_TX_Q_PACKETS,
> VIRTNET_RX_BYTES,
> VIRTNET_RX_PACKETS,
> + VIRTNET_RX_KICKS,
> + VIRTNET_RX_CBS,
> VIRTNET_NUM_STATS,
> };
>
> @@ -54,6 +60,21 @@ struct virtnet_stats {
> u64 data[VIRTNET_NUM_STATS];
> };
>
> +static struct {
> + char string[ETH_GSTRING_LEN];
> +} virtnet_stats_str_attr[] = {
> + { "tx_bytes" },
> + { "tx_packets" },
> + { "tx_kicks" },
> + { "tx_callbacks" },
> + { "tx_queued_bytes" },
> + { "tx_queued_packets" },
> + { "rx_bytes" },
> + { "rx_packets" },
> + { "rx_kicks" },
> + { "rx_callbacks" },
> +};
> +
> struct virtnet_info {
> struct virtio_device *vdev;
> struct virtqueue *rvq, *svq, *cvq;
> @@ -146,6 +167,11 @@ static struct page *get_a_page(struct virtnet_info *vi, gfp_t gfp_mask)
> static void skb_xmit_done(struct virtqueue *svq)
> {
> struct virtnet_info *vi = svq->vdev->priv;
> + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->data[VIRTNET_TX_CBS]++;
> + u64_stats_update_end(&stats->syncp);
>
> /* Suppress further interrupts. */
> virtqueue_disable_cb(svq);
> @@ -465,6 +491,7 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> {
> int err;
> bool oom;
> + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
>
> do {
> if (vi->mergeable_rx_bufs)
> @@ -481,13 +508,24 @@ static bool try_fill_recv(struct virtnet_info *vi, gfp_t gfp)
> } while (err > 0);
> if (unlikely(vi->num > vi->max))
> vi->max = vi->num;
> - virtqueue_kick(vi->rvq);
> + if (virtqueue_kick_prepare(vi->rvq)) {
> + virtqueue_notify(vi->rvq);
> + u64_stats_update_begin(&stats->syncp);
> + stats->data[VIRTNET_RX_KICKS]++;
> + u64_stats_update_end(&stats->syncp);
> + }
> return !oom;
> }
>
> static void skb_recv_done(struct virtqueue *rvq)
> {
> struct virtnet_info *vi = rvq->vdev->priv;
> + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->data[VIRTNET_RX_CBS]++;
> + u64_stats_update_end(&stats->syncp);
> +
> /* Schedule NAPI, Suppress further interrupts if successful. */
> if (napi_schedule_prep(&vi->napi)) {
> virtqueue_disable_cb(rvq);
> @@ -630,7 +668,9 @@ static int xmit_skb(struct virtnet_info *vi, struct sk_buff *skb)
> static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> + struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
> int capacity;
> + bool kick;
>
> /* Free up any pending old buffers before queueing new ones. */
> free_old_xmit_skbs(vi);
> @@ -655,7 +695,17 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
> kfree_skb(skb);
> return NETDEV_TX_OK;
> }
> - virtqueue_kick(vi->svq);
> +
> + kick = virtqueue_kick_prepare(vi->svq);
> + if (unlikely(kick))
> + virtqueue_notify(vi->svq);
> +
> + u64_stats_update_begin(&stats->syncp);
> + if (unlikely(kick))
> + stats->data[VIRTNET_TX_KICKS]++;
> + stats->data[VIRTNET_TX_Q_BYTES] += skb->len;
> + stats->data[VIRTNET_TX_Q_PACKETS]++;
is this statistic interesting?
how about decrementing when we free?
this way we see how many are pending..
> + u64_stats_update_end(&stats->syncp);
>
> /* Don't wait up for transmitted skbs to be freed. */
> skb_orphan(skb);
> @@ -943,10 +993,71 @@ static void virtnet_get_drvinfo(struct net_device *dev,
>
> }
>
> +static void virtnet_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
> +{
> + int i, cpu;
> + switch (stringset) {
> + case ETH_SS_STATS:
> + for_each_possible_cpu(cpu)
> + for (i = 0; i < VIRTNET_NUM_STATS; i++) {
> + sprintf(buf, "%s[%u]",
> + virtnet_stats_str_attr[i].string, cpu);
> + buf += ETH_GSTRING_LEN;
> + }
> + for (i = 0; i < VIRTNET_NUM_STATS; i++) {
> + memcpy(buf, virtnet_stats_str_attr[i].string,
> + ETH_GSTRING_LEN);
> + buf += ETH_GSTRING_LEN;
> + }
> + break;
> + }
> +}
> +
> +static int virtnet_get_sset_count(struct net_device *dev, int sset)
> +{
> + switch (sset) {
> + case ETH_SS_STATS:
> + return VIRTNET_NUM_STATS * (num_possible_cpus() + 1);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static void virtnet_get_ethtool_stats(struct net_device *dev,
> + struct ethtool_stats *stats, u64 *buf)
> +{
> + struct virtnet_info *vi = netdev_priv(dev);
> + int cpu, i;
> + unsigned int start;
> + struct virtnet_stats sample, total;
> +
> + memset(&total, 0, sizeof(total));
> +
> + for_each_possible_cpu(cpu) {
> + struct virtnet_stats *s = per_cpu_ptr(vi->stats, cpu);
> + do {
> + start = u64_stats_fetch_begin(&s->syncp);
> + memcpy(&sample.data, &s->data,
> + sizeof(u64) * VIRTNET_NUM_STATS);
> + } while (u64_stats_fetch_retry(&s->syncp, start));
> +
> + for (i = 0; i < VIRTNET_NUM_STATS; i++) {
> + *buf = sample.data[i];
> + total.data[i] += sample.data[i];
> + buf++;
> + }
> + }
> +
> + memcpy(buf, &total.data, sizeof(u64) * VIRTNET_NUM_STATS);
> +}
> +
> static const struct ethtool_ops virtnet_ethtool_ops = {
> .get_drvinfo = virtnet_get_drvinfo,
> .get_link = ethtool_op_get_link,
> .get_ringparam = virtnet_get_ringparam,
> + .get_ethtool_stats = virtnet_get_ethtool_stats,
> + .get_strings = virtnet_get_strings,
> + .get_sset_count = virtnet_get_sset_count,
> };
>
> #define MIN_MTU 68
^ permalink raw reply
* inetpeer in fib tables...
From: David Miller @ 2012-06-07 22:12 UTC (permalink / raw)
To: netdev
Just a heads up on what I'm doing to fix the bug Stephen Hemminger
forwarded.
Essentially I'm going to put inetpeer roots into the FIB tables.
Since each FIB table is essentially a realm of destinations, this will
fix all of the problems like the one in the bugzilla report.
We still need Gao's per-ns inetpeer root patches because there are
situations where we don't have a FIB table context by which to select
an inetpeer root, so we need a global inetpeer tree to fallback onto.
Several kinds of routing lookups do not use a FIB lookup. Also,
another case is the inetpeer lookup done for IPv4 fragmentation ID
wraparound avoidance.
Much of my changes have to do with handling the fact that we often
need to do the inetpeer lookup long after the route lookup. And we
don't want to waste a whole pointer just to store the inetpeer root.
So I change the rt->peer to be rt->_peer and of type unsigned long.
Then we encode the pointer with the low bit signifying that the
value is actually a pointer to an inetpeer base. Similar changes are
made for ipv6.
And similar handling is needed for TCP timewait sockets, to propagate
the inetpeer root to use for lookups or the fully resolved inetpeer.
The next problem is inetpeer tree invalidation. Now that we'll have
multiple trees per address family, we can't just flush all inetpeers
for a given address family so easily as we can now. The way this will
be handled is to give each peer a sequence number, and there is a
per-AF sequence number which will be bumped by the current
invalidation code. Lookups check the sequence number of the inetpeer
root they are using and flush if necessary.
Anyways, once Gao properly respins his patches I'll merge net into
net-next and start submitting the inetpeer FIB table changes.
^ permalink raw reply
* Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Jeff Kirsher @ 2012-06-07 22:02 UTC (permalink / raw)
To: David Miller
Cc: rkagan, e1000-devel, dnelson, bruce.w.allan, jesse.brandeburg,
stable, linux-kernel, john.ronciak, netdev
In-Reply-To: <20120607.144358.1732928576389957779.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 784 bytes --]
On 06/07/2012 02:43 PM, David Miller wrote:
> From: Jeff Kirsher <tarbal@gmail.com>
> Date: Thu, 07 Jun 2012 14:38:17 -0700
>
>> Thanks! I have applied the patch to my queue
> Why?
>
> My impression is that this is a patch already in the tree, and it's
> being submitted for -stable but such minor performance hacks are
> absolutely not appropriate for -stable submission.
I did not catch that Roman was trying to get this into stable because
there was no mention of what stable kernels this was applicable back to
(and the fact that it was a performance).
I thought he had found an issue with the previous commits and was
suggesting a fix to the previous patches.
Since he is trying to get this into -stable, disregard my statement
about adding it to my tree.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
[-- Attachment #2: Type: text/plain, Size: 395 bytes --]
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] usbnet: Activate the halt interrupt endpoint to fix endless "XactErr" error
From: David Miller @ 2012-06-07 21:54 UTC (permalink / raw)
To: huajun.li.lee; +Cc: linux-usb, netdev
In-Reply-To: <CA+v9cxYHq4gcy11SDmsuHUhTSdLJM-G0sugYnOjSthbYWA+1Yg@mail.gmail.com>
From: Huajun Li <huajun.li.lee@gmail.com>
Date: Tue, 5 Jun 2012 22:12:17 +0800
> There prints endless "XactErr" error msg once switch my device to the
> configuration
> which needs cdc_ether driver, the root cause is the interrupt endpoint halts.
> Maybe this is a common issue, so fix it by activating the endpoint
> once the error occurs.
>
> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
A USB expert needs to review this as I lack the knowledge to adequately
go over this patch.
^ permalink raw reply
* Re: [PATCH] snmp: fix OutOctets counter to include forwarded datagrams
From: David Miller @ 2012-06-07 21:53 UTC (permalink / raw)
To: bernat; +Cc: netdev, yoshfuji
In-Reply-To: <1338903702-18975-1-git-send-email-bernat@luffy.cx>
From: Vincent Bernat <bernat@luffy.cx>
Date: Tue, 5 Jun 2012 15:41:42 +0200
> RFC 4293 defines ipIfStatsOutOctets (similar definition for
> ipSystemStatsOutOctets):
>
> The total number of octets in IP datagrams delivered to the lower
> layers for transmission. Octets from datagrams counted in
> ipIfStatsOutTransmits MUST be counted here.
>
> And ipIfStatsOutTransmits:
>
> The total number of IP datagrams that this entity supplied to the
> lower layers for transmission. This includes datagrams generated
> locally and those forwarded by this entity.
>
> Therefore, IPSTATS_MIB_OUTOCTETS must be incremented when incrementing
> IPSTATS_MIB_OUTFORWDATAGRAMS.
>
> IP_UPD_PO_STATS is not used since ipIfStatsOutRequests must not
> include forwarded datagrams:
>
> The total number of IP datagrams that local IP user-protocols
> (including ICMP) supplied to IP in requests for transmission. Note
> that this counter does not include any datagrams counted in
> ipIfStatsOutForwDatagrams.
>
> Signed-off-by: Vincent Bernat <bernat@luffy.cx>
Applied, thanks for the detailed analysis.
^ permalink raw reply
* Re: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checks
From: David Miller @ 2012-06-07 21:53 UTC (permalink / raw)
To: phil; +Cc: netdev, phild
In-Reply-To: <20120605154058.GA16615@ipom.com>
From: Phil Dibowitz <phil@ipom.com>
Date: Tue, 5 Jun 2012 08:40:58 -0700
> and I want to make sure it makes it upstream by World v6 Launch Day.
Submitting a patch just a day or two beforehand is absolutely not the
way to achieve this.
It's a pointless deadline anyways, even if I put it in today it would
be months to years before the majority of real users actually have it
running on their machines.
^ permalink raw reply
* Re: [PATCH net-next] fec: Add support for Coldfire M5441x enet-mac.
From: David Miller @ 2012-06-07 21:47 UTC (permalink / raw)
To: sfking; +Cc: jan.ceuleers, netdev, uclinux-dev, gerg
In-Reply-To: <201206061305.48893.sfking@fdwdc.com>
From: Steven King <sfking@fdwdc.com>
Date: Wed, 6 Jun 2012 13:05:48 -0700
> On Wednesday 06 June 2012 10:34:21 am Jan Ceuleers wrote:
>> On 06/06/2012 07:06 PM, Steven King wrote:
>> > Add support for the Freescale Coldfire M5441x; as these parts have an
>> > enet-mac, add a quirk to distinguish them from the other Coldfire parts
>> > so we can use the existing enet-mac support.
>>
>> Stephen,
>>
>> You are activating certain functionality based on whether M5441x is
>> defined. But where is this being defined? Should this not be added in a
>> Kconfig somewhere as a platform option?
>
> Yes. Hopefully, once I send Greg my updated patches to add support for the
> m5441x, then it will be a selection in the m68k port. I just happened to
> have these ready to go after David chastised me for sending them too late in
> the last merge cycle...
I don't see any point in applying this before the necessary infrastructure
this depend upon is in the tree.
Therefore I'm not applying this.
^ permalink raw reply
* Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
From: David Miller @ 2012-06-07 21:43 UTC (permalink / raw)
To: jeffrey.t.kirsher, tarbal
Cc: rkagan, stable, jesse.brandeburg, bruce.w.allan, carolyn.wyborny,
donald.c.skidmore, gregory.v.rose, peter.p.waskiewicz.jr,
alexander.h.duyck, john.ronciak, dnelson, e1000-devel, netdev,
linux-kernel
In-Reply-To: <4FD11F49.5060805@gmail.com>
From: Jeff Kirsher <tarbal@gmail.com>
Date: Thu, 07 Jun 2012 14:38:17 -0700
> Thanks! I have applied the patch to my queue
Why?
My impression is that this is a patch already in the tree, and it's
being submitted for -stable but such minor performance hacks are
absolutely not appropriate for -stable submission.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: David Miller @ 2012-06-07 21:43 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w
In-Reply-To: <20120606.104323.1698446129331745479.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 06 Jun 2012 10:43:23 -0700 (PDT)
> So I'm dropping these two patches and will work on the mentioned
> approach to this fix.
It turns out that even if I move the inetpeer roots into the FIB rules
layer, we still need your changes Gao.
But your patches are corrupted. For example, in this patch,
the final hunk for net/ipv4/inetpeer.c has no differences only
context. That's an extremely corrupted patch.
Please resolve this, and add the NULL pointer settings during network
namespace shutdown that Eric Dumazet asked for.
Thanks.
^ permalink raw reply
* Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Jeff Kirsher @ 2012-06-07 21:38 UTC (permalink / raw)
To: Roman Kagan
Cc: stable, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, Dean Nelson, David S. Miller,
e1000-devel, netdev, linux-kernel
In-Reply-To: <b838d871c0d507787373061e4edd91a624d62475.1339073391.git.rkagan@parallels.com>
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
On 06/07/2012 05:49 AM, Roman Kagan wrote:
> [Upstream commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec with paths
> adjusted to compensate for the drivers/net/ethernet/intel reorg in
> dee1ad47f2ee75f5146d83ca757c1b7861c34c3b]
>
> Author: Dean Nelson <dnelson@redhat.com>
> Date: Thu Aug 25 14:39:24 2011 +0000
>
> e1000: save skb counts in TX to avoid cache misses
>
> Virtual Machines with emulated e1000 network adapter running on Parallels'
> server were seeing kernel panics due to the e1000 driver dereferencing an
> unexpected NULL pointer retrieved from buffer_info->skb.
>
> The problem has been addressed for the e1000e driver, but not for the e1000.
> Since the two drivers share similar code in the affected area, a port of the
> following e1000e driver commit solves the issue for the e1000 driver:
>
> commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
> Author: Tom Herbert <therbert@google.com>
> Date: Wed May 5 14:02:27 2010 +0000
>
> e1000e: save skb counts in TX to avoid cache misses
>
> In e1000_tx_map, precompute number of segements and bytecounts which
> are derived from fields in skb; these are stored in buffer_info. When
> cleaning tx in e1000_clean_tx_irq use the values in the associated
> buffer_info for statistics counting, this eliminates cache misses
> on skb fields.
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Roman Kagan <rkagan@parallels.com>
> ---
> drivers/net/e1000/e1000.h | 2 ++
> drivers/net/e1000/e1000_main.c | 18 +++++++++---------
> 2 files changed, 11 insertions(+), 9 deletions(-)
Thanks! I have applied the patch to my queue
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply
* Re: [PATCH] fix kernel crash in the macvlan driver
From: Ani Sinha @ 2012-06-07 21:32 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, Francesco Ruggeri
In-Reply-To: <alpine.OSX.2.00.1206071320040.86561@animac.local>
>
> Now since, macvlan_common_newlink() symbol has been exported but dellink() is not, it
oops, sorry. Not sure what I was looking at. dellink() has also been
exported and is used by macvtap.c. So no issues here.
ani
^ permalink raw reply
* RE: NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
From: Huang, Xiong @ 2012-06-07 21:30 UTC (permalink / raw)
To: Thomas Meyer, Jonathan Nieder
Cc: Eric Dumazet, Linux Kernel Mailing List, jcliburn@gmail.com,
chris.snook@gmail.com, netdev, Josh Boyer
In-Reply-To: <1339072653.3018.9.camel@localhost.localdomain>
Thomas
Are you using the latest atl1c code in kernel ? recently, I have updated some hw configuration.
Thanks
Xiong
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Thomas Meyer
> Sent: Thursday, June 07, 2012 20:38
> To: Jonathan Nieder
> Cc: Eric Dumazet; Linux Kernel Mailing List; jcliburn@gmail.com;
> chris.snook@gmail.com; netdev; Josh Boyer
> Subject: Re: NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
>
> Am Dienstag, den 05.06.2012, 19:38 -0500 schrieb Jonathan Nieder:
> > In February, 2012, Thomas Meyer wrote:
> > > Am Freitag, den 24.02.2012, 20:20 +0100 schrieb Eric Dumazet:
> >
> > >> Here is a cumulative patch to hopefuly remove the races in this
> > >> driver, could you please test it ?
> > [...]
> > > just building a 3.2.7 kernel with your patch applied. I will watch
> > > out for the warning in the next days.
> >
> > Well, did it work? :)
>
> Hi Jonathan,
>
> no it didn't. I still get these warnings.
>
> wiht kind regards
> thomas
>
> >
> > In suspense,
> > Jonathan
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Eric Dumazet @ 2012-06-07 21:30 UTC (permalink / raw)
To: Francois Romieu; +Cc: Denys Fedoryshchenko, davem, netdev, linux-kernel
In-Reply-To: <20120607205356.GA2491@electric-eye.fr.zoreil.com>
On Thu, 2012-06-07 at 22:53 +0200, Francois Romieu wrote:
> Any reason why it could not be made LLTX ?
>
> /* via l2tp_session_priv() */
> @@ -87,25 +95,56 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct l2tp_eth *priv = netdev_priv(dev);
> struct l2tp_session *session = priv->session;
> + struct l2tp_eth_stats *tstats = &priv->tstats;
>
> l2tp_xmit_skb(session, skb, session->hdr_len);
>
> - dev->stats.tx_bytes += skb->len;
> - dev->stats.tx_packets++;
> + u64_stats_update_begin(&tstats->syncp);
> + tstats->packets++;
> + tstats->bytes += skb->len;
> + u64_stats_update_end(&tstats->syncp);
>
> return 0;
> }
>
Its racy.
If LLTX is used, this means several cpus can execute this code at the
same time.
You need percpu stats, or use atomic primitives.
^ permalink raw reply
* Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
From: Ben Hutchings @ 2012-06-07 20:58 UTC (permalink / raw)
To: Rick Jones; +Cc: mst, netdev, linux-kernel, virtualization, David Miller
In-Reply-To: <1339102567.2770.25.camel@bwh-desktop.uk.solarflarecom.com>
On Thu, 2012-06-07 at 21:56 +0100, Ben Hutchings wrote:
> On Thu, 2012-06-07 at 13:39 -0700, Rick Jones wrote:
> > On 06/07/2012 01:24 PM, Ben Hutchings wrote:
> > > On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
> > >> From: Ben Hutchings<bhutchings@solarflare.com>
> > >> Date: Thu, 7 Jun 2012 18:15:06 +0100
> > >>
> > >>> I would really like to see some sort of convention for presenting
> > >>> per-queue statistics through ethtool. At the moment we have a complete
> > >>> mess of different formats:
> > >>
> > >> Indeed. Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
> > >> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
> > >> etc.
> > >
> > > I think we should leave the type names open-ended, as there are other
> > > useful groupings like per-virtual-port. In that case the separator
> > > should be chosen to allow arbitrary type names without ambiguity.
> >
> > So you mean like something along the lines of the presence of say '.'
> > indicating indent a level:
> >
> > rx_bytes: 1234
> > myqueue1.rx_bytes: 234
> > myqueue2.rx_bytes: 345
> > ...
>
> Most drivers seem to want this sort of ordering/grouping:
>
> group0.foo
> group0.bar
> ...
> group1.foo
> group1.bar
> ...
>
> but if we have a standard way of indicating groups of statistics then
> the user can choose whether they want to reorder by type name.
I mean, whether they want to reorder/regroup by the final part of the
statistic name.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox