* Re: [PATCH] neigh: __rcu annotations
From: Paul E. McKenney @ 2011-01-22 1:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1295510567.2653.487.camel@edumazet-laptop>
On Thu, Jan 20, 2011 at 09:02:47AM +0100, Eric Dumazet wrote:
> fix some minor issues and sparse (__rcu) warnings
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/core/neighbour.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 60a9029..799f06e 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -316,7 +316,7 @@ static struct neigh_hash_table *neigh_hash_alloc(unsigned int entries)
> {
> size_t size = entries * sizeof(struct neighbour *);
> struct neigh_hash_table *ret;
> - struct neighbour **buckets;
> + struct neighbour __rcu **buckets;
>
> ret = kmalloc(sizeof(*ret), GFP_ATOMIC);
> if (!ret)
> @@ -324,14 +324,14 @@ static struct neigh_hash_table *neigh_hash_alloc(unsigned int entries)
> if (size <= PAGE_SIZE)
> buckets = kzalloc(size, GFP_ATOMIC);
> else
> - buckets = (struct neighbour **)
> + buckets = (struct neighbour __rcu **)
> __get_free_pages(GFP_ATOMIC | __GFP_ZERO,
> get_order(size));
> if (!buckets) {
> kfree(ret);
> return NULL;
> }
> - rcu_assign_pointer(ret->hash_buckets, buckets);
> + ret->hash_buckets = buckets;
> ret->hash_mask = entries - 1;
> get_random_bytes(&ret->hash_rnd, sizeof(ret->hash_rnd));
> return ret;
> @@ -343,7 +343,7 @@ static void neigh_hash_free_rcu(struct rcu_head *head)
> struct neigh_hash_table,
> rcu);
> size_t size = (nht->hash_mask + 1) * sizeof(struct neighbour *);
> - struct neighbour **buckets = nht->hash_buckets;
> + struct neighbour __rcu **buckets = nht->hash_buckets;
>
> if (size <= PAGE_SIZE)
> kfree(buckets);
> @@ -1540,7 +1540,7 @@ void neigh_table_init_no_netlink(struct neigh_table *tbl)
> panic("cannot create neighbour proc dir entry");
> #endif
>
> - tbl->nht = neigh_hash_alloc(8);
> + RCU_INIT_POINTER(tbl->nht, neigh_hash_alloc(8));
>
> phsize = (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *);
> tbl->phash_buckets = kzalloc(phsize, GFP_KERNEL);
> @@ -1602,7 +1602,8 @@ int neigh_table_clear(struct neigh_table *tbl)
> }
> write_unlock(&neigh_tbl_lock);
>
> - call_rcu(&tbl->nht->rcu, neigh_hash_free_rcu);
> + call_rcu(&rcu_dereference_protected(tbl->nht, 1)->rcu,
> + neigh_hash_free_rcu);
Hello, Eric,
Any chance of a comment? Perhaps something like:
/*
* Because this has been removed from the list, no other updater
* can access this element.
*/
Thanx, Paul
> tbl->nht = NULL;
>
> kfree(tbl->phash_buckets);
>
>
> --
> 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: [RFC] ipv6: don't flush routes when setting loopback down
From: Eric W. Biederman @ 2011-01-22 8:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Bohac, David Miller, brian.haley, netdev, maheshkelkar,
lorenzo, yoshfuji, stable
In-Reply-To: <20110119120123.40974cbe@s6510>
Stephen Hemminger <shemminger@vyatta.com> writes:
> On Wed, 19 Jan 2011 20:56:32 +0100
> Jiri Bohac <jbohac@suse.cz> wrote:
>
>> On Wed, Jan 19, 2011 at 11:38:17AM -0800, Stephen Hemminger wrote:
>> > Jiri Bohac <jbohac@suse.cz> wrote:
>> > > I have the feeling that Eric's patch is the safest solution we
>> > > have so far:
>> > Eric's patch has other regressions, see the discussion.
>>
>> What regression do you mean? I have read the whole discussion
>> thoroughly. You only say in one message that deleting ::1 would
>> propagate to routing daemons. And Eric correctly stated that
>> people couldn't hit this, because deleting ::1 would break
>> things on its own.
>>
>> Is there a real problem with Eric's fix?
>>
>> Thanks,
>>
>
> If address is assigned to loopback interface (other than ::1) then
> Eric's fix doesn't work. It is common to use an additional address
> on the lo device when doing routing protocols.
Sigh.
I just got back to looking through the rest of my failures in 2.6.37 and
despite it looking like it worked when i tested it, your patch doesn't
actually work on my real work load that has broken.
At least your change that confirmed that the root problem is somewhere
in the routing.
Eric
^ permalink raw reply
* Re: [PATCH v2 1/3] can: at91_can: clean up usage of AT91_MB_RX_FIRST and AT91_MB_RX_NUM
From: Kurt Van Dijck @ 2011-01-22 7:50 UTC (permalink / raw)
To: David Miller
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <20110121.165409.200115988.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Jan 21, 2011 at 04:54:09PM -0800, David Miller wrote:
> > On 01/11/2011 02:21 PM, Marc Kleine-Budde wrote:
> >> This patch cleans up the usage of two macros which specify the mailbox
> >> usage. AT91_MB_RX_FIRST and AT91_MB_RX_NUM define the first and the
> >> number of RX mailboxes. The current driver uses these variables in an
> >> unclean way; assuming that AT91_MB_RX_FIRST is 0;
> >>
> >> This patch cleans up the usage of these macros, no longer assuming
> >> AT91_MB_RX_FIRST == 0.
> >>
> >> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > Any comments on this?
>
> I would also seriously like to see these changes get some feedback,
> they've been rotting in patchwork for more than a week.
I have no experience with this specific chip.
IMO, this chip errata (as explained in the post) got an elegant solution.
That part definitely gets my
Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Regards,
Kurt
^ permalink raw reply
* Re: [PATCH v2 1/3] can: at91_can: clean up usage of AT91_MB_RX_FIRST and AT91_MB_RX_NUM
From: Wolfgang Grandegger @ 2011-01-22 7:14 UTC (permalink / raw)
To: David Miller
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20110121.165409.200115988.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 01/22/2011 01:54 AM, David Miller wrote:
> From: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Date: Mon, 17 Jan 2011 20:50:36 +0100
>
>> On 01/11/2011 02:21 PM, Marc Kleine-Budde wrote:
>>> This patch cleans up the usage of two macros which specify the mailbox
>>> usage. AT91_MB_RX_FIRST and AT91_MB_RX_NUM define the first and the
>>> number of RX mailboxes. The current driver uses these variables in an
>>> unclean way; assuming that AT91_MB_RX_FIRST is 0;
>>>
>>> This patch cleans up the usage of these macros, no longer assuming
>>> AT91_MB_RX_FIRST == 0.
>>>
>>> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>
>> Any comments on this?
>
> I would also seriously like to see these changes get some feedback,
> they've been rotting in patchwork for more than a week.
V2 was OK and it got my "Acked-by" here:
http://marc.info/?l=linux-netdev&m=129534267002747&w=2
Wolfgang.
^ permalink raw reply
* Re: [RFC PATCH] ipsec: fix IPv4 AH alignment on 32 bits
From: David Miller @ 2011-01-22 4:20 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, christophe.gouault
In-Reply-To: <4D2F3453.9020203@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 13 Jan 2011 18:20:19 +0100
> here is a patch to fix alignment of IPv4 AH. Note that this break
> compatiblity for some algorithms (like SHA256) with old kernels
> ... but upstream cannot use SHA256 on IPv4, for example, with a target
> that is RFC compliant.
>
> I don't know what is the best way to fix this.
We cannot just start rejecting the old 8-byte alignment on input if
Linux has been using an 8-byte alignment since day one.
If you want this change to be considered seriously, you need to relax
the AH4 input check.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v3 0/2] can: add driver for Softing card
From: David Miller @ 2011-01-22 4:17 UTC (permalink / raw)
To: kurt.van.dijck-/BeEPy95v10
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20110111143007.GB387-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
From: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Date: Tue, 11 Jan 2011 15:30:08 +0100
> This series will add a driver for Softing PCMCIA CAN card.
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-22 3:12 UTC (permalink / raw)
To: Changli Gao
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel
In-Reply-To: <20110122031116.GA8443@verge.net.au>
On Sat, Jan 22, 2011 at 02:11:16PM +1100, Simon Horman wrote:
> On Sat, Jan 22, 2011 at 10:34:23AM +0800, Changli Gao wrote:
> > On Sat, Jan 22, 2011 at 10:22 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Fri, Jan 21, 2011 at 06:02:13PM +0800, Changli Gao wrote:
> > >> Fix compiler warnings when no transport protocol load balancing support
> > >> is configured.
> > >>
> > >> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> > >> ---
> > >> net/netfilter/ipvs/ip_vs_core.c | 4 +---
> > >> net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
> > >> net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
> > >> 3 files changed, 9 insertions(+), 3 deletions(-)
> > >> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> > >> index f36a84f..d889f4f 100644
> > >> --- a/net/netfilter/ipvs/ip_vs_core.c
> > >> +++ b/net/netfilter/ipvs/ip_vs_core.c
> > >> @@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
> > >>
> > >> static void __net_exit __ip_vs_cleanup(struct net *net)
> > >> {
> > >> - struct netns_ipvs *ipvs = net_ipvs(net);
> > >> -
> > >> - IP_VS_DBG(10, "ipvs netns %d released\n", ipvs->gen);
> > >> + IP_VS_DBG(10, "ipvs netns %d released\n", net_ipvs(net)->gen);
> > >> }
> > >>
> > >
> > > The hunk above seems unrelated to the problem described.
> > > The rest of the changes look good. I will double check and
> > > apply them to my tree.
> > >
> >
> > Yes, is a separated patch needed? It is trivial. Thanks.
>
> Yes, please send a separate patch.
To clarify, I have applied the other hunks and included
them in a pull request that I sent to Patrick a few moments ago.
^ permalink raw reply
* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-22 3:11 UTC (permalink / raw)
To: Changli Gao
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel
In-Reply-To: <AANLkTimoSQbjH-iW6x36FHs6yzDgsey9RS+yFXnKOxq5@mail.gmail.com>
On Sat, Jan 22, 2011 at 10:34:23AM +0800, Changli Gao wrote:
> On Sat, Jan 22, 2011 at 10:22 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Jan 21, 2011 at 06:02:13PM +0800, Changli Gao wrote:
> >> Fix compiler warnings when no transport protocol load balancing support
> >> is configured.
> >>
> >> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> >> ---
> >> net/netfilter/ipvs/ip_vs_core.c | 4 +---
> >> net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
> >> net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
> >> 3 files changed, 9 insertions(+), 3 deletions(-)
> >> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> >> index f36a84f..d889f4f 100644
> >> --- a/net/netfilter/ipvs/ip_vs_core.c
> >> +++ b/net/netfilter/ipvs/ip_vs_core.c
> >> @@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
> >>
> >> static void __net_exit __ip_vs_cleanup(struct net *net)
> >> {
> >> - struct netns_ipvs *ipvs = net_ipvs(net);
> >> -
> >> - IP_VS_DBG(10, "ipvs netns %d released\n", ipvs->gen);
> >> + IP_VS_DBG(10, "ipvs netns %d released\n", net_ipvs(net)->gen);
> >> }
> >>
> >
> > The hunk above seems unrelated to the problem described.
> > The rest of the changes look good. I will double check and
> > apply them to my tree.
> >
>
> Yes, is a separated patch needed? It is trivial. Thanks.
Yes, please send a separate patch.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* [PATCH 1/2] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-22 3:10 UTC (permalink / raw)
To: lvs-devel, netfilter-devel, netdev
Cc: Changli Gao, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
Simon Horman
In-Reply-To: <1295665835-8708-1-git-send-email-horms@verge.net.au>
From: Changli Gao <xiaosuo@gmail.com>
Fix compiler warnings when no transport protocol load balancing support
is configured.
[horms@verge.net.au: removed suprious __ip_vs_cleanup() clean-up hunk]
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 09ca2ce..68b8033 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2062,7 +2062,9 @@ static const struct file_operations ip_vs_stats_percpu_fops = {
*/
static int ip_vs_set_timeout(struct net *net, struct ip_vs_timeout_user *u)
{
+#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
struct ip_vs_proto_data *pd;
+#endif
IP_VS_DBG(2, "Setting timeout tcp:%d tcpfin:%d udp:%d\n",
u->tcp_timeout,
@@ -2405,7 +2407,9 @@ __ip_vs_get_dest_entries(struct net *net, const struct ip_vs_get_dests *get,
static inline void
__ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
{
+#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
struct ip_vs_proto_data *pd;
+#endif
#ifdef CONFIG_IP_VS_PROTO_TCP
pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index 6ac986c..17484a4 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -60,6 +60,9 @@ static int __used __init register_ip_vs_protocol(struct ip_vs_protocol *pp)
return 0;
}
+#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP) || \
+ defined(CONFIG_IP_VS_PROTO_SCTP) || defined(CONFIG_IP_VS_PROTO_AH) || \
+ defined(CONFIG_IP_VS_PROTO_ESP)
/*
* register an ipvs protocols netns related data
*/
@@ -85,6 +88,7 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
return 0;
}
+#endif
/*
* unregister an ipvs protocol
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] IPVS: Change sock_create_kernel() to __sock_create()
From: Simon Horman @ 2011-01-22 3:10 UTC (permalink / raw)
To: lvs-devel, netfilter-devel, netdev
Cc: Changli Gao, Hans Schillstrom, Julian Anastasov, Patrick McHardy,
Simon Horman
In-Reply-To: <1295665835-8708-1-git-send-email-horms@verge.net.au>
The recent netns changes omitted to change
sock_create_kernel() to __sock_create() in ip_vs_sync.c
The effect of this is that the interface will be selected in the
root-namespace, from my point of view it's a major bug.
Reported-by: Hans Schillstrom <hans@schillstrom.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_sync.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index d1adf98..d5a6e64 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -1305,7 +1305,7 @@ static struct socket *make_send_sock(struct net *net)
int result;
/* First create a socket */
- result = sock_create_kern(PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
+ result = __sock_create(net, PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock, 1);
if (result < 0) {
pr_err("Error during creation of socket; terminating\n");
return ERR_PTR(result);
@@ -1351,7 +1351,7 @@ static struct socket *make_receive_sock(struct net *net)
int result;
/* First create a socket */
- result = sock_create_kern(PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
+ result = __sock_create(net, PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock, 1);
if (result < 0) {
pr_err("Error during creation of socket; terminating\n");
return ERR_PTR(result);
--
1.7.2.3
^ permalink raw reply related
* [GIT PULL nf-next-2.6] IPVS updates for v2.6.38-rc1
From: Simon Horman @ 2011-01-22 3:10 UTC (permalink / raw)
To: lvs-devel, netfilter-devel, netdev
Cc: Changli Gao, Hans Schillstrom, Julian Anastasov, Patrick McHardy
Hi Patrick, please consider pulling
git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
This includes bugfixes by Changli Gao and Hans Schillstrom.
Changli Gao (1):
netfilter: ipvs: fix compiler warnings
Simon Horman (1):
IPVS: Change sock_create_kernel() to __sock_create()
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
net/netfilter/ipvs/ip_vs_sync.c | 4 ++--
3 files changed, 10 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] net: dcbnl: remove redundant DCB_CAP_DCBX_STATIC bit
From: John Fastabend @ 2011-01-22 2:52 UTC (permalink / raw)
To: davem@davemloft.net, shmulikr@broadcom.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110122023512.4239.40379.stgit@jf-dev1-dcblab>
On 1/21/2011 6:35 PM, John Fastabend wrote:
> Remove redundant DCB_CAP_DCBX_STATIC bit in DCB capabilities
>
> Setting this bit indicates that no embedded DCBx engine is
> present and the hardware can not be configured. This is the
> same as having none of the DCB capability flags set or simply
> not implementing the dcbnl ops at all.
>
> This patch removes this bit. The bit has not made a stable
> release yet so removing it should not be an issue with
> existing apps.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> CC: Shmulik Ravid <shmulikr@broadcom.com>
> ---
>
Shmulik, could you ACK this because you added these bits? But
I was adding support for this in lldpad and I see no reason that
we need these?
Thanks,
John.
^ permalink raw reply
* [net-2.6 PATCH 1/2] net: dcbnl: remove redundant DCB_CAP_DCBX_STATIC bit
From: John Fastabend @ 2011-01-22 2:35 UTC (permalink / raw)
To: davem, shmulikr; +Cc: netdev
Remove redundant DCB_CAP_DCBX_STATIC bit in DCB capabilities
Setting this bit indicates that no embedded DCBx engine is
present and the hardware can not be configured. This is the
same as having none of the DCB capability flags set or simply
not implementing the dcbnl ops at all.
This patch removes this bit. The bit has not made a stable
release yet so removing it should not be an issue with
existing apps.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
CC: Shmulik Ravid <shmulikr@broadcom.com>
---
include/linux/dcbnl.h | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index 68cd248..ac9df34 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -423,18 +423,11 @@ enum dcbnl_cap_attrs {
*
* @DCB_CAP_DCBX_VER_IEEE: for a non-host DCBX engine, indicates the engine
* supports the IEEE protocol flavor
- *
- * @DCB_CAP_DCBX_STATIC: for a non-host DCBX engine, indicates the engine
- * supports static configuration (i.e no actual
- * negotiation is performed negotiated parameters equal
- * the initial configuration)
- *
*/
#define DCB_CAP_DCBX_HOST 0x01
#define DCB_CAP_DCBX_LLD_MANAGED 0x02
#define DCB_CAP_DCBX_VER_CEE 0x04
#define DCB_CAP_DCBX_VER_IEEE 0x08
-#define DCB_CAP_DCBX_STATIC 0x10
/**
* enum dcbnl_numtcs_attrs - number of traffic classes
^ permalink raw reply related
* [net-2.6 PATCH 2/2] dcbnl: make get_app handling symmetric for IEEE and CEE DCBx
From: John Fastabend @ 2011-01-22 2:35 UTC (permalink / raw)
To: davem, shmulikr; +Cc: netdev
In-Reply-To: <20110122023512.4239.40379.stgit@jf-dev1-dcblab>
The IEEE get/set app handlers use generic routines and do not
require the net_device to implement the dcbnl_ops routines. This
patch makes it symmetric so user space and drivers do not have
to handle the CEE version and IEEE DCBx versions differently.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/dcb/dcbnl.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index d900ab9..6b03f56 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -583,7 +583,7 @@ static int dcbnl_getapp(struct net_device *netdev, struct nlattr **tb,
u8 up, idtype;
int ret = -EINVAL;
- if (!tb[DCB_ATTR_APP] || !netdev->dcbnl_ops->getapp)
+ if (!tb[DCB_ATTR_APP])
goto out;
ret = nla_parse_nested(app_tb, DCB_APP_ATTR_MAX, tb[DCB_ATTR_APP],
@@ -604,7 +604,16 @@ static int dcbnl_getapp(struct net_device *netdev, struct nlattr **tb,
goto out;
id = nla_get_u16(app_tb[DCB_APP_ATTR_ID]);
- up = netdev->dcbnl_ops->getapp(netdev, idtype, id);
+
+ if (netdev->dcbnl_ops->getapp) {
+ up = netdev->dcbnl_ops->getapp(netdev, idtype, id);
+ } else {
+ struct dcb_app app = {
+ .selector = idtype,
+ .protocol = id,
+ };
+ up = dcb_getapp(netdev, &app);
+ }
/* send this back */
dcbnl_skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
^ permalink raw reply related
* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Changli Gao @ 2011-01-22 2:34 UTC (permalink / raw)
To: Simon Horman
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel
In-Reply-To: <20110122022232.GL2661@verge.net.au>
On Sat, Jan 22, 2011 at 10:22 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Jan 21, 2011 at 06:02:13PM +0800, Changli Gao wrote:
>> Fix compiler warnings when no transport protocol load balancing support
>> is configured.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> ---
>> net/netfilter/ipvs/ip_vs_core.c | 4 +---
>> net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
>> net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
>> 3 files changed, 9 insertions(+), 3 deletions(-)
>> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
>> index f36a84f..d889f4f 100644
>> --- a/net/netfilter/ipvs/ip_vs_core.c
>> +++ b/net/netfilter/ipvs/ip_vs_core.c
>> @@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
>>
>> static void __net_exit __ip_vs_cleanup(struct net *net)
>> {
>> - struct netns_ipvs *ipvs = net_ipvs(net);
>> -
>> - IP_VS_DBG(10, "ipvs netns %d released\n", ipvs->gen);
>> + IP_VS_DBG(10, "ipvs netns %d released\n", net_ipvs(net)->gen);
>> }
>>
>
> The hunk above seems unrelated to the problem described.
> The rest of the changes look good. I will double check and
> apply them to my tree.
>
Yes, is a separated patch needed? It is trivial. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-22 2:22 UTC (permalink / raw)
To: Changli Gao
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel
In-Reply-To: <1295604133-6869-1-git-send-email-xiaosuo@gmail.com>
On Fri, Jan 21, 2011 at 06:02:13PM +0800, Changli Gao wrote:
> Fix compiler warnings when no transport protocol load balancing support
> is configured.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/netfilter/ipvs/ip_vs_core.c | 4 +---
> net/netfilter/ipvs/ip_vs_ctl.c | 4 ++++
> net/netfilter/ipvs/ip_vs_proto.c | 4 ++++
> 3 files changed, 9 insertions(+), 3 deletions(-)
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index f36a84f..d889f4f 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
>
> static void __net_exit __ip_vs_cleanup(struct net *net)
> {
> - struct netns_ipvs *ipvs = net_ipvs(net);
> -
> - IP_VS_DBG(10, "ipvs netns %d released\n", ipvs->gen);
> + IP_VS_DBG(10, "ipvs netns %d released\n", net_ipvs(net)->gen);
> }
>
The hunk above seems unrelated to the problem described.
The rest of the changes look good. I will double check and
apply them to my tree.
Patrick, I have another fix. So I think it would be best
to take this fix though my tree and. I'll send you a pull
request shortly.
> static struct pernet_operations ipvs_core_ops = {
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 09ca2ce..68b8033 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2062,7 +2062,9 @@ static const struct file_operations ip_vs_stats_percpu_fops = {
> */
> static int ip_vs_set_timeout(struct net *net, struct ip_vs_timeout_user *u)
> {
> +#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> struct ip_vs_proto_data *pd;
> +#endif
>
> IP_VS_DBG(2, "Setting timeout tcp:%d tcpfin:%d udp:%d\n",
> u->tcp_timeout,
> @@ -2405,7 +2407,9 @@ __ip_vs_get_dest_entries(struct net *net, const struct ip_vs_get_dests *get,
> static inline void
> __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> {
> +#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> struct ip_vs_proto_data *pd;
> +#endif
>
> #ifdef CONFIG_IP_VS_PROTO_TCP
> pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
> diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
> index 6ac986c..17484a4 100644
> --- a/net/netfilter/ipvs/ip_vs_proto.c
> +++ b/net/netfilter/ipvs/ip_vs_proto.c
> @@ -60,6 +60,9 @@ static int __used __init register_ip_vs_protocol(struct ip_vs_protocol *pp)
> return 0;
> }
>
> +#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP) || \
> + defined(CONFIG_IP_VS_PROTO_SCTP) || defined(CONFIG_IP_VS_PROTO_AH) || \
> + defined(CONFIG_IP_VS_PROTO_ESP)
> /*
> * register an ipvs protocols netns related data
> */
> @@ -85,6 +88,7 @@ register_ip_vs_proto_netns(struct net *net, struct ip_vs_protocol *pp)
>
> return 0;
> }
> +#endif
>
> /*
> * unregister an ipvs protocol
>
^ permalink raw reply
* Re: [PATCH] xen: netfront: Drop GSO SKBs which do not have csum_blank.
From: Jeremy Fitzhardinge @ 2011-01-22 0:58 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, xen-devel
In-Reply-To: <1294233811-28123-1-git-send-email-ian.campbell@citrix.com>
On 01/05/2011 05:23 AM, Ian Campbell wrote:
> The Linux network stack expects all GSO SKBs to have ip_summed ==
> CHECKSUM_PARTIAL (which implies that the frame contains a partial
> checksum) and the Xen network ring protocol similarly expects an SKB
> which has GSO set to also have NETRX_csum_blank (which also implies a
> partial checksum). Therefore drop such frames on receive otherwise
> they will trigger the warning in skb_gso_segment.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/xen-netfront.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index cdbeec9..8b8c480 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -836,6 +836,11 @@ static int handle_incoming_queue(struct net_device *dev,
> dev->stats.rx_errors++;
> continue;
> }
> + } else if (skb_is_gso(skb)) {
> + kfree_skb(skb);
> + packets_dropped++;
> + dev->stats.rx_errors++;
> + continue;
This looks redundant; why not something like:
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 47e6a71..c1b8f64 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -852,13 +852,12 @@ static int handle_incoming_queue(struct net_device *dev,
/* Ethernet work: Delayed to here as it peeks the header. */
skb->protocol = eth_type_trans(skb, dev);
- if (skb->ip_summed == CHECKSUM_PARTIAL) {
- if (skb_checksum_setup(skb)) {
- kfree_skb(skb);
- packets_dropped++;
- dev->stats.rx_errors++;
- continue;
- }
+ if (skb->ip_summed != CHECKSUM_PARTIAL ||
+ skb_checksum_setup(skb)) {
+ kfree_skb(skb);
+ packets_dropped++;
+ dev->stats.rx_errors++;
+ continue;
}
dev->stats.rx_packets++;
Thanks,
J
^ permalink raw reply related
* Re: [PATCH 5/8] af_unix: find the recipients of a multicast group
From: David Miller @ 2011-01-22 0:58 UTC (permalink / raw)
To: alban.crequy; +Cc: eric.dumazet, lennart, netdev, linux-kernel, ian.molton
In-Reply-To: <20110121172420.7ac74133@chocolatine.cbg.collabora.co.uk>
From: Alban Crequy <alban.crequy@collabora.co.uk>
Date: Fri, 21 Jan 2011 17:24:20 +0000
> I don't know if I should avoid releasing sockets in RCU callbacks or
> update the lockdep annotations.
Releasing sockets in RCU callbacks is dangerous at best.
^ permalink raw reply
* Re: [PATCH v2 1/3] can: at91_can: clean up usage of AT91_MB_RX_FIRST and AT91_MB_RX_NUM
From: David Miller @ 2011-01-22 0:54 UTC (permalink / raw)
To: mkl; +Cc: Socketcan-core, netdev, wg
In-Reply-To: <4D349D8C.3010403@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 17 Jan 2011 20:50:36 +0100
> On 01/11/2011 02:21 PM, Marc Kleine-Budde wrote:
>> This patch cleans up the usage of two macros which specify the mailbox
>> usage. AT91_MB_RX_FIRST and AT91_MB_RX_NUM define the first and the
>> number of RX mailboxes. The current driver uses these variables in an
>> unclean way; assuming that AT91_MB_RX_FIRST is 0;
>>
>> This patch cleans up the usage of these macros, no longer assuming
>> AT91_MB_RX_FIRST == 0.
>>
>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> Any comments on this?
I would also seriously like to see these changes get some feedback,
they've been rotting in patchwork for more than a week.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net_sched: TCQ_F_CAN_BYPASS generalization
From: David Miller @ 2011-01-22 0:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber, hawk, jarkao2, hadi
In-Reply-To: <1295607881.2601.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Jan 2011 12:04:41 +0100
> Now qdisc stab is handled before TCQ_F_CAN_BYPASS test in
> __dev_xmit_skb(), we can generalize TCQ_F_CAN_BYPASS to other qdiscs
> than pfifo_fast : pfifo, bfifo, pfifo_head_drop and sfq
>
> SFQ is special because it can have external classifiers, and in these
> cases, we cannot bypass queue discipline (packet could be dropped by
> classifier) without admin asking it, or further changes.
>
> Its worth doing this, especially for SFQ, avoiding dirtying memory in
> case no packets are already waiting in queue.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
> I am not sure RED can use bypass too, feel free to comment on this ;)
The only thing that RED would seem to care about would be the
queue size average calculation.
^ permalink raw reply
* Re: [PATCH] atm: idt77105: fix fetch_stats() result
From: David Miller @ 2011-01-22 0:24 UTC (permalink / raw)
To: segoon; +Cc: kernel-janitors, chas, linux-atm-general, netdev, linux-kernel
In-Reply-To: <1295602987-11688-1-git-send-email-segoon@openwall.com>
From: Vasiliy Kulikov <segoon@openwall.com>
Date: Fri, 21 Jan 2011 12:43:07 +0300
> copy_to_user() used PRIV(dev)->stats instead of local stats variable.
> Zero stats were returned to user in case of (zero != 0), also memcpy()
> was pointless.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode.
From: Mahesh Bandewar @ 2011-01-22 0:23 UTC (permalink / raw)
To: David Miller
Cc: Ben Hutchings, Tom Herbert, Laurent Chavey, netdev,
Mahesh Bandewar
In-Reply-To: <1294187401-4662-1-git-send-email-maheshb@google.com>
This patch enables ethtool to set the loopback mode on a given interface.
By configuring the interface in loopback mode in conjunction with a policy
route / rule, a userland application can stress the egress / ingress path
exposing the flows of the change in progress and potentially help developer(s)
understand the impact of those changes without even sending a packet out
on the network.
Following set of commands illustrates one such example -
a) ip -4 addr add 192.168.1.1/24 dev eth1
b) ip -4 rule add from all iif eth1 lookup 250
c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
d) arp -Ds 192.168.1.100 eth1
e) arp -Ds 192.168.1.200 eth1
f) sysctl -w net.ipv4.ip_nonlocal_bind=1
g) sysctl -w net.ipv4.conf.all.accept_local=1
# Assuming that the machine has 8 cores
h) taskset 000f netserver -L 192.168.1.200
i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/ethtool.h | 16 ++++++++++++++++
net/core/ethtool.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 1908929..1b12541 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -616,6 +616,18 @@ void ethtool_ntuple_flush(struct net_device *dev);
* Should validate the magic field. Don't need to check len for zero
* or wraparound. Update len to the amount written. Returns an error
* or zero.
+ *
+ * get_loopback:
+ * set_loopback:
+ * These are the driver specific get / set methods to report / enable-
+ * disable loopback mode. The idea is to stress test the ingress/egress
+ * paths by enabling this mode. There are multiple places this could be
+ * done and choice of place will most likely be affected by the device
+ * capabilities. So as a guiding principle; select a place to implement
+ * loopback mode as close to the host as possible. This would maximize
+ * the soft-path length and maintain parity in terms of comparison with
+ * different set of drivers.
+ *
*/
struct ethtool_ops {
int (*get_settings)(struct net_device *, struct ethtool_cmd *);
@@ -678,6 +690,8 @@ struct ethtool_ops {
struct ethtool_rxfh_indir *);
int (*set_rxfh_indir)(struct net_device *,
const struct ethtool_rxfh_indir *);
+ int (*get_loopback)(struct net_device *, u32 *);
+ int (*set_loopback)(struct net_device *, u32);
};
#endif /* __KERNEL__ */
@@ -743,6 +757,8 @@ struct ethtool_ops {
#define ETHTOOL_GSSET_INFO 0x00000037 /* Get string set info */
#define ETHTOOL_GRXFHINDIR 0x00000038 /* Get RX flow hash indir'n table */
#define ETHTOOL_SRXFHINDIR 0x00000039 /* Set RX flow hash indir'n table */
+#define ETHTOOL_SLOOPBACK 0x0000003a /* Enable / Disable Loopback */
+#define ETHTOOL_GLOOPBACK 0x0000003b /* Get Loopback status */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 1774178..7a5f11a 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1450,6 +1450,39 @@ static noinline_for_stack int ethtool_flash_device(struct net_device *dev,
return dev->ethtool_ops->flash_device(dev, &efl);
}
+static int ethtool_set_loopback(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_value edata;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops || !ops->set_loopback)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&edata, useraddr, sizeof(edata)))
+ return -EFAULT;
+
+ return ops->set_loopback(dev, edata.data);
+}
+
+static int ethtool_get_loopback(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_value edata;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+ int err;
+
+ if (!ops || !ops->get_loopback)
+ return -EOPNOTSUPP;
+
+ err = ops->get_loopback(dev, &edata.data);
+ if (err)
+ return (err);
+
+ if (copy_to_user(useraddr, &edata, sizeof(edata)))
+ return -EFAULT;
+
+ return 0;
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1693,6 +1726,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SRXFHINDIR:
rc = ethtool_set_rxfh_indir(dev, useraddr);
break;
+ case ETHTOOL_SLOOPBACK:
+ rc = ethtool_set_loopback(dev, useraddr);
+ break;
+ case ETHTOOL_GLOOPBACK:
+ rc = ethtool_get_loopback(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.3.1
^ permalink raw reply related
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-21 23:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rick Jones, Jesse Gross, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110121095929.GE26070@redhat.com>
On Fri, Jan 21, 2011 at 11:59:30AM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 20, 2011 at 05:38:33PM +0900, Simon Horman wrote:
> > [ Trimmed Eric from CC list as vger was complaining that it is too long ]
> >
> > On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
> > > >So it won't be all that simple to implement well, and before we try,
> > > >I'd like to know whether there are applications that are helped
> > > >by it. For example, we could try to measure latency at various
> > > >pps and see whether the backpressure helps. netperf has -b, -w
> > > >flags which might help these measurements.
> > >
> > > Those options are enabled when one adds --enable-burst to the
> > > pre-compilation ./configure of netperf (one doesn't have to
> > > recompile netserver). However, if one is also looking at latency
> > > statistics via the -j option in the top-of-trunk, or simply at the
> > > histogram with --enable-histogram on the ./configure and a verbosity
> > > level of 2 (global -v 2) then one wants the very top of trunk
> > > netperf from:
> >
> > Hi,
> >
> > I have constructed a test where I run an un-paced UDP_STREAM test in
> > one guest and a paced omni rr test in another guest at the same time.
>
> Hmm, what is this supposed to measure? Basically each time you run an
> un-paced UDP_STREAM you get some random load on the network.
> You can't tell what it was exactly, only that it was between
> the send and receive throughput.
Rick mentioned in another email that I messed up my test parameters a bit,
so I will re-run the tests, incorporating his suggestions.
What I was attempting to measure was the effect of an unpaced UDP_STREAM
on the latency of more moderated traffic. Because I am interested in
what effect an abusive guest has on other guests and how that my be
mitigated.
Could you suggest some tests that you feel are more appropriate?
^ permalink raw reply
* Re: [PATCH v2] e1000e: convert to stats64
From: Jeff Kirsher @ 2011-01-21 22:19 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
In-Reply-To: <20110121170340.GA3087@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]
On Fri, 2011-01-21 at 09:03 -0800, Flavio Leitner wrote:
> On Thu, Dec 16, 2010 at 07:14:35PM -0800, Jeff Kirsher wrote:
> > On Thu, Dec 16, 2010 at 04:31, Flavio Leitner <fleitner@redhat.com> wrote:
> > > On Tue, Dec 14, 2010 at 10:29:33PM +0100, Eric Dumazet wrote:
> > >> Le mardi 14 décembre 2010 à 18:32 -0200, Flavio Leitner a écrit :
> > >> > Provides accurate stats at the time user reads them.
> > >> >
> > >> > Signed-off-by: Flavio Leitner <fleitner@redhat.com>
> > >> > ---
> > >> > drivers/net/e1000e/e1000.h | 5 ++-
> > >> > drivers/net/e1000e/ethtool.c | 27 +++++++++-------
> > >> > drivers/net/e1000e/netdev.c | 68 ++++++++++++++++++++++++-----------------
> > >> > 3 files changed, 59 insertions(+), 41 deletions(-)
> > >> >
> > >> > diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
> > >> > index fdc67fe..5a5e944 100644
> > >> > --- a/drivers/net/e1000e/e1000.h
> > >> > +++ b/drivers/net/e1000e/e1000.h
> > >> > @@ -363,6 +363,8 @@ struct e1000_adapter {
> > >> > /* structs defined in e1000_hw.h */
> > >> > struct e1000_hw hw;
> > >> >
> > >> > + spinlock_t stats64_lock;
> > >> > + struct rtnl_link_stats64 stats64;
> > >>
> > >> I am not sure why you add this stats64 in e1000_adapter ?
> > >>
> > >> Why isnt it provided by callers (automatic variable, or provided to
> > >> ndo_get_stats64()). I dont see accumulators, only a full rewrite of this
> > >> structure in e1000e_update_stats() ?
> > >
> > > Good point. I have modified the patch to fix that.
> > > thanks!
> > >
> > > From 3487bd7dacd0c23bba315270139dab6e00e5ff02 Mon Sep 17 00:00:00 2001
> > > From: Flavio Leitner <fleitner@redhat.com>
> > > Date: Thu, 16 Dec 2010 10:26:03 -0200
> > > Subject: [PATCH] e1000e: convert to stats64
> > >
> > > Provides accurate stats at the time user reads them.
> > >
> > > Signed-off-by: Flavio Leitner <fleitner@redhat.com>
> > > ---
> > > drivers/net/e1000e/e1000.h | 3 ++
> > > drivers/net/e1000e/ethtool.c | 25 ++++++++-------
> > > drivers/net/e1000e/netdev.c | 68 +++++++++++++++++++++++++++++++++--------
> > > 3 files changed, 70 insertions(+), 26 deletions(-)
> > >
> >
> > I have dropped you previous version of the patch and applied v2 to my
> > tree for review and testing.
> > Thanks Flavio!
>
> Hi Jeff,
>
> Do you have any feedback on this patch?
> thanks,
I have the patch ready to push to Dave for net-next, along with a few
other e1000e patches. I was just waiting for net-next to open (which it
did a few days ago).
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6
From: Brandeburg, Jesse @ 2011-01-21 22:15 UTC (permalink / raw)
To: Hans de Bruin; +Cc: Eric Dumazet, Jesse Gross, netdev
In-Reply-To: <4D39EEDA.90902@xmsnet.nl>
On Fri, 21 Jan 2011, Hans de Bruin wrote:
> > tcpdump gets a copy of outgoing frames before NIC performs tx checksum
> > (if tx checksum handled by NIC), so it's normal to have "bad checksums"
> > on TX, unless you disable tx offloading (ethtool -K eth0 tx off)
>
> That seem reasonable but: the bug was triggered because my nic could not
> offload checksumming, so what's tx=on if there's no support for it? I
> have turned tx off and my tcpdump still shows bad checksums on outgoing
> tcp/ip6 packets. I have tried 2.6.36: bad checksums, 2.6.35 and
> surprise: good checksums with tx=on.
maybe you're still seeing confusing output on tx due to GSO, try turning
that off with ethtool -K ethX gso off
GSO still software-segments packets, and maybe the tap for tcpdump is
before GSO operation.
> > I was referring to check with tcpdump incoming frames, because invalid
> > checksums in RX is sign that other peer sent wrong checksums
>
> Ok, thats clear, the receiving site is apparently a more reliable
> checksummer than the sending site.
>
>
^ 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