All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] net: Fix vlan_gro_frags vs netpoll and bonding paths
@ 2010-08-27 20:50 Jarek Poplawski
  2010-08-28  0:13 ` Herbert Xu
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-27 20:50 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Herbert Xu, Patrick McHardy

After positive netpoll_rx_on() check in vlan_gro_receive() there is
skipped part of the "common" GRO_NORMAL path, especially "pull:" in
dev_gro_receive(), where at least eth header should be copied for
entirely paged skbs. So, eth_type_trans() can read zeroed header only.

Alas moving the netpoll_rx_on() check isn't enough here because a bit
later, in vlan_gro_common(), skb_bond_should_drop() is called, which
depends on skb->protocol and skb->pkt_type data, and can also change
eth_hdr h_dest address (which is overwritten later, btw).

To fix both problems this patch completes copying and verifying of eth
header from the fragment in vlan_gro_receive(). For that purpose the
"pull:" part of dev_gro_receive() was separated into an inline as
skb_gro_pull_in(), and there was added a "lighter" version of
napi_frags_finish(). No gro path except vlan_gro_frags() should be
affected by these changes.

Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---

 include/linux/netdevice.h |   33 ++++++++++++++++++++++++++++++
 net/8021q/vlan_core.c     |   16 ++++++++++----
 net/core/dev.c            |   48 +++++++++++++++++++++++++-------------------
 3 files changed, 71 insertions(+), 26 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 46c36ff..ad59f76 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1339,6 +1339,36 @@ static inline void skb_gro_pull(struct sk_buff *skb, unsigned int len)
 	NAPI_GRO_CB(skb)->data_offset += len;
 }
 
+/*
+ * Complete pulling of the header(s) from the fragment
+ */
+static inline void skb_gro_pull_in(struct sk_buff *skb)
+{
+	int grow;
+
+	if (skb_headlen(skb) >= skb_gro_offset(skb))
+		return;
+
+	grow = skb_gro_offset(skb) - skb_headlen(skb);
+
+	BUG_ON(skb->end - skb->tail < grow);
+
+	memcpy(skb_tail_pointer(skb), NAPI_GRO_CB(skb)->frag0, grow);
+
+	skb->tail += grow;
+	skb->data_len -= grow;
+
+	skb_shinfo(skb)->frags[0].page_offset += grow;
+	skb_shinfo(skb)->frags[0].size -= grow;
+
+	if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
+		put_page(skb_shinfo(skb)->frags[0].page);
+		memmove(skb_shinfo(skb)->frags,
+			skb_shinfo(skb)->frags + 1,
+			--skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
+	}
+}
+
 static inline void *skb_gro_header_fast(struct sk_buff *skb,
 					unsigned int offset)
 {
@@ -1701,6 +1731,9 @@ extern struct sk_buff *	napi_get_frags(struct napi_struct *napi);
 extern gro_result_t	napi_frags_finish(struct napi_struct *napi,
 					  struct sk_buff *skb,
 					  gro_result_t ret);
+extern gro_result_t	__napi_frags_finish(struct napi_struct *napi,
+					    struct sk_buff *skb,
+					    gro_result_t ret);
 extern struct sk_buff *	napi_frags_skb(struct napi_struct *napi);
 extern gro_result_t	napi_gro_frags(struct napi_struct *napi);
 
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 01ddb04..58289fe 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -139,13 +139,19 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
 	if (!skb)
 		return GRO_DROP;
 
-	if (netpoll_rx_on(skb)) {
-		skb->protocol = eth_type_trans(skb, skb->dev);
+	/*
+	 * Complete the eth header here, mainly for skb_bond_should_drop(),
+	 * and for netpoll_rx_on() btw.
+	 */
+	skb_gro_pull_in(skb);
+	skb->protocol = eth_type_trans(skb, skb->dev);
+	skb_gro_pull(skb, -ETH_HLEN);
+
+	if (netpoll_rx_on(skb))
 		return vlan_hwaccel_receive_skb(skb, grp, vlan_tci)
 			? GRO_DROP : GRO_NORMAL;
-	}
 
-	return napi_frags_finish(napi, skb,
-				 vlan_gro_common(napi, grp, vlan_tci, skb));
+	return __napi_frags_finish(napi, skb,
+				   vlan_gro_common(napi, grp, vlan_tci, skb));
 }
 EXPORT_SYMBOL(vlan_gro_frags);
diff --git a/net/core/dev.c b/net/core/dev.c
index 3721fbb..cdc0be5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3126,27 +3126,7 @@ enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
 	ret = GRO_HELD;
 
 pull:
-	if (skb_headlen(skb) < skb_gro_offset(skb)) {
-		int grow = skb_gro_offset(skb) - skb_headlen(skb);
-
-		BUG_ON(skb->end - skb->tail < grow);
-
-		memcpy(skb_tail_pointer(skb), NAPI_GRO_CB(skb)->frag0, grow);
-
-		skb->tail += grow;
-		skb->data_len -= grow;
-
-		skb_shinfo(skb)->frags[0].page_offset += grow;
-		skb_shinfo(skb)->frags[0].size -= grow;
-
-		if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
-			put_page(skb_shinfo(skb)->frags[0].page);
-			memmove(skb_shinfo(skb)->frags,
-				skb_shinfo(skb)->frags + 1,
-				--skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
-		}
-	}
-
+	skb_gro_pull_in(skb);
 ok:
 	return ret;
 
@@ -3267,6 +3247,32 @@ gro_result_t napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb,
 }
 EXPORT_SYMBOL(napi_frags_finish);
 
+/*
+ * The lighter version of napi_frags_finish() without eth_type_trans() etc.
+ */
+gro_result_t __napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb,
+				 gro_result_t ret)
+{
+	switch (ret) {
+	case GRO_NORMAL:
+		if (netif_receive_skb(skb))
+			ret = GRO_DROP;
+		break;
+
+	case GRO_DROP:
+	case GRO_MERGED_FREE:
+		napi_reuse_skb(napi, skb);
+		break;
+
+	case GRO_HELD:
+	case GRO_MERGED:
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(__napi_frags_finish);
+
 struct sk_buff *napi_frags_skb(struct napi_struct *napi)
 {
 	struct sk_buff *skb = napi->skb;

^ permalink raw reply related	[flat|nested] 41+ messages in thread

* Re: [PATCH] net: Fix vlan_gro_frags vs netpoll and bonding paths
  2010-08-27 20:50 [PATCH] net: Fix vlan_gro_frags vs netpoll and bonding paths Jarek Poplawski
@ 2010-08-28  0:13 ` Herbert Xu
  2010-08-28  9:44   ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: Herbert Xu @ 2010-08-28  0:13 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: David Miller, netdev, Patrick McHardy

On Fri, Aug 27, 2010 at 10:50:42PM +0200, Jarek Poplawski wrote:
> After positive netpoll_rx_on() check in vlan_gro_receive() there is
> skipped part of the "common" GRO_NORMAL path, especially "pull:" in
> dev_gro_receive(), where at least eth header should be copied for
> entirely paged skbs. So, eth_type_trans() can read zeroed header only.

Right, thanks for catching this.

> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index 01ddb04..58289fe 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -139,13 +139,19 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
>  	if (!skb)
>  		return GRO_DROP;
>  
> -	if (netpoll_rx_on(skb)) {
> -		skb->protocol = eth_type_trans(skb, skb->dev);
> +	/*
> +	 * Complete the eth header here, mainly for skb_bond_should_drop(),
> +	 * and for netpoll_rx_on() btw.
> +	 */
> +	skb_gro_pull_in(skb);
> +	skb->protocol = eth_type_trans(skb, skb->dev);
> +	skb_gro_pull(skb, -ETH_HLEN);

But this code should go into the netpoll (i.e., slow-path) case
only so as not to impede performance.

Also, we need to fix this for the non-VLAN case as well.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] net: Fix vlan_gro_frags vs netpoll and bonding paths
  2010-08-28  0:13 ` Herbert Xu
@ 2010-08-28  9:44   ` Jarek Poplawski
  2010-08-28 10:54     ` [RFC] gro: Is it ok to share a single napi from several devs ? Eric Dumazet
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-28  9:44 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David Miller, netdev, Patrick McHardy

On Sat, Aug 28, 2010 at 08:13:37AM +0800, Herbert Xu wrote:
> On Fri, Aug 27, 2010 at 10:50:42PM +0200, Jarek Poplawski wrote:
> > After positive netpoll_rx_on() check in vlan_gro_receive() there is
> > skipped part of the "common" GRO_NORMAL path, especially "pull:" in
> > dev_gro_receive(), where at least eth header should be copied for
> > entirely paged skbs. So, eth_type_trans() can read zeroed header only.
> 
> Right, thanks for catching this.
> 
> > diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> > index 01ddb04..58289fe 100644
> > --- a/net/8021q/vlan_core.c
> > +++ b/net/8021q/vlan_core.c
> > @@ -139,13 +139,19 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
> >  	if (!skb)
> >  		return GRO_DROP;
> >  
> > -	if (netpoll_rx_on(skb)) {
> > -		skb->protocol = eth_type_trans(skb, skb->dev);
> > +	/*
> > +	 * Complete the eth header here, mainly for skb_bond_should_drop(),
> > +	 * and for netpoll_rx_on() btw.
> > +	 */
> > +	skb_gro_pull_in(skb);
> > +	skb->protocol = eth_type_trans(skb, skb->dev);
> > +	skb_gro_pull(skb, -ETH_HLEN);
> 
> But this code should go into the netpoll (i.e., slow-path) case
> only so as not to impede performance.

I'm not sure I can understand. What about skb_bond_should_drop()
mentioned in the comments? IMHO we have to impede performance a bit
(and treat it similarly to non-fragmented path) just to fix it, and
consider optimization of this bonding call later.

> 
> Also, we need to fix this for the non-VLAN case as well.

But the only other non-VLAN case I know was fixed already...

Cheers,
Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28  9:44   ` Jarek Poplawski
@ 2010-08-28 10:54     ` Eric Dumazet
  2010-08-28 14:31       ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: Eric Dumazet @ 2010-08-28 10:54 UTC (permalink / raw)
  To: Jarek Poplawski, Stephen Hemminger; +Cc: Herbert Xu, David Miller, netdev

In commit f2bde7328633269ee935d9ed96535ade15cc348f
Author: Stephen Hemminger <shemminger@vyatta.com>

    net: allow multiple dev per napi with GRO
    
    GRO assumes that there is a one-to-one relationship between NAPI
    structure and network device. Some devices like sky2 share multiple
    devices on a single interrupt so only have one NAPI handler. Rather than
    split GRO from NAPI, just have GRO assume if device changes that
    it is a different flow.
   

It was assumed a napi could be shared by several devs, but I dont really
understand, since we have an unique ->dev pointer inside "napi_struct",
this one is set once, and never change.

This pointer is currently used from napi_get_frags() [but that could be
avoided], and from netpoll_poll_lock().

The netpoll_poll_lock() case is problematic.

static inline void *netpoll_poll_lock(struct napi_struct *napi)
{
        struct net_device *dev = napi->_dev;

        if (dev && dev->npinfo) {
                spin_lock(&napi->poll_lock);

Maybe we should remove 'dev' field from napi_struct and replace it by a
npinfo pointer ?





^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 10:54     ` [RFC] gro: Is it ok to share a single napi from several devs ? Eric Dumazet
@ 2010-08-28 14:31       ` Jarek Poplawski
  2010-08-28 14:48         ` Eric Dumazet
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-28 14:31 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Stephen Hemminger, Herbert Xu, David Miller, netdev

On Sat, Aug 28, 2010 at 12:54:06PM +0200, Eric Dumazet wrote:
> In commit f2bde7328633269ee935d9ed96535ade15cc348f
> Author: Stephen Hemminger <shemminger@vyatta.com>
> 
>     net: allow multiple dev per napi with GRO
>     
>     GRO assumes that there is a one-to-one relationship between NAPI
>     structure and network device. Some devices like sky2 share multiple
>     devices on a single interrupt so only have one NAPI handler. Rather than
>     split GRO from NAPI, just have GRO assume if device changes that
>     it is a different flow.
>    
> 
> It was assumed a napi could be shared by several devs, but I dont really
> understand, since we have an unique ->dev pointer inside "napi_struct",
> this one is set once, and never change.
> 
> This pointer is currently used from napi_get_frags() [but that could be
> avoided], and from netpoll_poll_lock().
> 
> The netpoll_poll_lock() case is problematic.
> 
> static inline void *netpoll_poll_lock(struct napi_struct *napi)
> {
>         struct net_device *dev = napi->_dev;
> 
>         if (dev && dev->npinfo) {
>                 spin_lock(&napi->poll_lock);
> 
> Maybe we should remove 'dev' field from napi_struct and replace it by a
> npinfo pointer ?

Sky2 seems to work like a single netdev (with an internal sub-netdev),
so I can't see your concern: what is the main aim of this replacement?

Jarek P. 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 14:31       ` Jarek Poplawski
@ 2010-08-28 14:48         ` Eric Dumazet
  2010-08-28 15:16           ` Jarek Poplawski
  2010-08-28 17:14           ` Stephen Hemminger
  0 siblings, 2 replies; 41+ messages in thread
From: Eric Dumazet @ 2010-08-28 14:48 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: Stephen Hemminger, Herbert Xu, David Miller, netdev

Le samedi 28 août 2010 à 16:31 +0200, Jarek Poplawski a écrit :
> On Sat, Aug 28, 2010 at 12:54:06PM +0200, Eric Dumazet wrote:
> > In commit f2bde7328633269ee935d9ed96535ade15cc348f
> > Author: Stephen Hemminger <shemminger@vyatta.com>
> > 
> >     net: allow multiple dev per napi with GRO
> >     
> >     GRO assumes that there is a one-to-one relationship between NAPI
> >     structure and network device. Some devices like sky2 share multiple
> >     devices on a single interrupt so only have one NAPI handler. Rather than
> >     split GRO from NAPI, just have GRO assume if device changes that
> >     it is a different flow.
> >    
> > 
> > It was assumed a napi could be shared by several devs, but I dont really
> > understand, since we have an unique ->dev pointer inside "napi_struct",
> > this one is set once, and never change.
> > 
> > This pointer is currently used from napi_get_frags() [but that could be
> > avoided], and from netpoll_poll_lock().
> > 
> > The netpoll_poll_lock() case is problematic.
> > 
> > static inline void *netpoll_poll_lock(struct napi_struct *napi)
> > {
> >         struct net_device *dev = napi->_dev;
> > 
> >         if (dev && dev->npinfo) {
> >                 spin_lock(&napi->poll_lock);
> > 
> > Maybe we should remove 'dev' field from napi_struct and replace it by a
> > npinfo pointer ?
> 
> Sky2 seems to work like a single netdev (with an internal sub-netdev),
> so I can't see your concern: what is the main aim of this replacement?

I am trying to understand why this commit was needed then.

It adds an extra test in the main loop, testing skb->dev against p->dev,
it must me for something...

I am trying to say that the one to one relationship between NAPI
structure and a device is not only a GRO thing, but also a netpoll one.

So either we completely remove this one to one relationship, either
Stephen commit was not needed.

Some clarification is needed.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 14:48         ` Eric Dumazet
@ 2010-08-28 15:16           ` Jarek Poplawski
  2010-08-28 17:14           ` Stephen Hemminger
  1 sibling, 0 replies; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-28 15:16 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Stephen Hemminger, Herbert Xu, David Miller, netdev

On Sat, Aug 28, 2010 at 04:48:29PM +0200, Eric Dumazet wrote:
> Le samedi 28 ao??t 2010 ?? 16:31 +0200, Jarek Poplawski a écrit :
> > On Sat, Aug 28, 2010 at 12:54:06PM +0200, Eric Dumazet wrote:
> > > In commit f2bde7328633269ee935d9ed96535ade15cc348f
> > > Author: Stephen Hemminger <shemminger@vyatta.com>
> > > 
> > >     net: allow multiple dev per napi with GRO
> > >     
> > >     GRO assumes that there is a one-to-one relationship between NAPI
> > >     structure and network device. Some devices like sky2 share multiple
> > >     devices on a single interrupt so only have one NAPI handler. Rather than
> > >     split GRO from NAPI, just have GRO assume if device changes that
> > >     it is a different flow.
> > >    
> > > 
> > > It was assumed a napi could be shared by several devs, but I dont really
> > > understand, since we have an unique ->dev pointer inside "napi_struct",
> > > this one is set once, and never change.
> > > 
> > > This pointer is currently used from napi_get_frags() [but that could be
> > > avoided], and from netpoll_poll_lock().
> > > 
> > > The netpoll_poll_lock() case is problematic.
> > > 
> > > static inline void *netpoll_poll_lock(struct napi_struct *napi)
> > > {
> > >         struct net_device *dev = napi->_dev;
> > > 
> > >         if (dev && dev->npinfo) {
> > >                 spin_lock(&napi->poll_lock);
> > > 
> > > Maybe we should remove 'dev' field from napi_struct and replace it by a
> > > npinfo pointer ?
> > 
> > Sky2 seems to work like a single netdev (with an internal sub-netdev),
> > so I can't see your concern: what is the main aim of this replacement?
> 
> I am trying to understand why this commit was needed then.
> 
> It adds an extra test in the main loop, testing skb->dev against p->dev,
> it must me for something...
> 
> I am trying to say that the one to one relationship between NAPI
> structure and a device is not only a GRO thing, but also a netpoll one.

I guess it's not about the full one to one relationship, but kind of
overloading (pseudo vlan?). How much it's needed is another question,
but at least the order of these tests seems doubtful.

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 14:48         ` Eric Dumazet
  2010-08-28 15:16           ` Jarek Poplawski
@ 2010-08-28 17:14           ` Stephen Hemminger
  2010-08-28 21:41             ` David Miller
  1 sibling, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-28 17:14 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Jarek Poplawski, Herbert Xu, David Miller, netdev

On Sat, 28 Aug 2010 16:48:29 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le samedi 28 août 2010 à 16:31 +0200, Jarek Poplawski a écrit :
> > On Sat, Aug 28, 2010 at 12:54:06PM +0200, Eric Dumazet wrote:
> > > In commit f2bde7328633269ee935d9ed96535ade15cc348f
> > > Author: Stephen Hemminger <shemminger@vyatta.com>
> > > 
> > >     net: allow multiple dev per napi with GRO
> > >     
> > >     GRO assumes that there is a one-to-one relationship between NAPI
> > >     structure and network device. Some devices like sky2 share multiple
> > >     devices on a single interrupt so only have one NAPI handler. Rather than
> > >     split GRO from NAPI, just have GRO assume if device changes that
> > >     it is a different flow.
> > >    
> > > 
> > > It was assumed a napi could be shared by several devs, but I dont really
> > > understand, since we have an unique ->dev pointer inside "napi_struct",
> > > this one is set once, and never change.
> > > 
> > > This pointer is currently used from napi_get_frags() [but that could be
> > > avoided], and from netpoll_poll_lock().
> > > 
> > > The netpoll_poll_lock() case is problematic.
> > > 
> > > static inline void *netpoll_poll_lock(struct napi_struct *napi)
> > > {
> > >         struct net_device *dev = napi->_dev;
> > > 
> > >         if (dev && dev->npinfo) {
> > >                 spin_lock(&napi->poll_lock);
> > > 
> > > Maybe we should remove 'dev' field from napi_struct and replace it by a
> > > npinfo pointer ?
> > 
> > Sky2 seems to work like a single netdev (with an internal sub-netdev),
> > so I can't see your concern: what is the main aim of this replacement?
> 
> I am trying to understand why this commit was needed then.
> 
> It adds an extra test in the main loop, testing skb->dev against p->dev,
> it must me for something...
> 
> I am trying to say that the one to one relationship between NAPI
> structure and a device is not only a GRO thing, but also a netpoll one.
> 
> So either we completely remove this one to one relationship, either
> Stephen commit was not needed.
> 
> Some clarification is needed.
> 
> 

The Marvell Yukon2 hardware supports two interfaces sharing a common interrupt.
Therfore the sky2 driver has up to two net devices and a single NAPI per board.
It is possible in a single invocation of the poll loop to process frames
for both ports.  GRO works by combining received packets from identical
flows over one NAPI interval. It is possible on sky2 that one packet
could be processed for the first port, and the next packet processed was for
second port and the two packets were related so that GRO would combine them.
The check for the same dev is required to prevent this. Yes it is an unlikely
corner case, but the purpose of GRO is to do aggregation but preserve the
flow characteristics of the incoming traffic.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 17:14           ` Stephen Hemminger
@ 2010-08-28 21:41             ` David Miller
  2010-08-28 22:31               ` Stephen Hemminger
  2010-08-29  9:59               ` Jarek Poplawski
  0 siblings, 2 replies; 41+ messages in thread
From: David Miller @ 2010-08-28 21:41 UTC (permalink / raw)
  To: shemminger; +Cc: eric.dumazet, jarkao2, herbert, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 28 Aug 2010 10:14:24 -0700

> The Marvell Yukon2 hardware supports two interfaces sharing a common interrupt.
> Therfore the sky2 driver has up to two net devices and a single NAPI per board.
> It is possible in a single invocation of the poll loop to process frames
> for both ports.  GRO works by combining received packets from identical
> flows over one NAPI interval. It is possible on sky2 that one packet
> could be processed for the first port, and the next packet processed was for
> second port and the two packets were related so that GRO would combine them.
> The check for the same dev is required to prevent this. Yes it is an unlikely
> corner case, but the purpose of GRO is to do aggregation but preserve the
> flow characteristics of the incoming traffic.

If that is true then GRO is going to refuse to merge every single
frame that arrives on the second port of a SKY2 device. :-)

This is because for the two ports, you allocate and register one NAPI
instance which uses only the first port's netdev pointer.

Therefore, when GRO compares napi->dev to skb->dev it will always not
match for packets coming from the second port since the netdev pointer
in skb->dev will be different.

Since netpoll does similar things, this means both NAPI and netpoll
cannot function properly with SKY2's second port.  It will only work
right on the first port.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 21:41             ` David Miller
@ 2010-08-28 22:31               ` Stephen Hemminger
  2010-08-28 22:33                 ` David Miller
  2010-08-29  9:59               ` Jarek Poplawski
  1 sibling, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-28 22:31 UTC (permalink / raw)
  To: David Miller; +Cc: eric.dumazet, jarkao2, herbert, netdev

On Sat, 28 Aug 2010 14:41:30 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> Since netpoll does similar things, this means both NAPI and netpoll
> cannot function properly with SKY2's second port.  It will only work
> right on the first port.

I knew netpoll was broken on second port.

-- 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 22:31               ` Stephen Hemminger
@ 2010-08-28 22:33                 ` David Miller
  0 siblings, 0 replies; 41+ messages in thread
From: David Miller @ 2010-08-28 22:33 UTC (permalink / raw)
  To: shemminger; +Cc: eric.dumazet, jarkao2, herbert, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 28 Aug 2010 15:31:24 -0700

> On Sat, 28 Aug 2010 14:41:30 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
>> Since netpoll does similar things, this means both NAPI and netpoll
>> cannot function properly with SKY2's second port.  It will only work
>> right on the first port.
> 
> I knew netpoll was broken on second port.

Well, now we know that GRO is too :-)

If we wish to keep the one-to-one mapping of NAPI contexts to
interrupt sources, what we can do is provide some kind of "dev list".

The other option is to register two NAPI contexts and schedule them
both on an interrupt.

But in both cases, detecting the end of polling, and thus when to turn
the interrupts back on, is non-trivial.

I really don't like either solution, therefore, so I'll try to brain
storm on this a bit more.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-28 21:41             ` David Miller
  2010-08-28 22:31               ` Stephen Hemminger
@ 2010-08-29  9:59               ` Jarek Poplawski
  2010-08-29 17:06                 ` David Miller
  1 sibling, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-29  9:59 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, eric.dumazet, herbert, netdev

On Sat, Aug 28, 2010 at 02:41:30PM -0700, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Sat, 28 Aug 2010 10:14:24 -0700
> 
> > The Marvell Yukon2 hardware supports two interfaces sharing a common interrupt.
> > Therfore the sky2 driver has up to two net devices and a single NAPI per board.
> > It is possible in a single invocation of the poll loop to process frames
> > for both ports.  GRO works by combining received packets from identical
> > flows over one NAPI interval. It is possible on sky2 that one packet
> > could be processed for the first port, and the next packet processed was for
> > second port and the two packets were related so that GRO would combine them.
> > The check for the same dev is required to prevent this. Yes it is an unlikely
> > corner case, but the purpose of GRO is to do aggregation but preserve the
> > flow characteristics of the incoming traffic.
> 
> If that is true then GRO is going to refuse to merge every single
> frame that arrives on the second port of a SKY2 device. :-)
> 
> This is because for the two ports, you allocate and register one NAPI
> instance which uses only the first port's netdev pointer.
> 
> Therefore, when GRO compares napi->dev to skb->dev it will always not

Actually, when GRO compares napi->dev to skb->dev?

Jarek P.

> match for packets coming from the second port since the netdev pointer
> in skb->dev will be different.
> 
> Since netpoll does similar things, this means both NAPI and netpoll
> cannot function properly with SKY2's second port.  It will only work
> right on the first port.
> 
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-29  9:59               ` Jarek Poplawski
@ 2010-08-29 17:06                 ` David Miller
  2010-08-29 18:39                   ` Eric Dumazet
  0 siblings, 1 reply; 41+ messages in thread
From: David Miller @ 2010-08-29 17:06 UTC (permalink / raw)
  To: jarkao2; +Cc: shemminger, eric.dumazet, herbert, netdev

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sun, 29 Aug 2010 11:59:51 +0200

> Actually, when GRO compares napi->dev to skb->dev?

Hmmm, I thought the code made a skb->dev comparison with the
existing SKBs in the list when checking for same-flow matches.

It doesn't, probably based upon the assumption that a NAPI
instance maps to a unique device, the very topic we're
discussing right now :-/



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-29 17:06                 ` David Miller
@ 2010-08-29 18:39                   ` Eric Dumazet
  2010-08-30  6:42                     ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: Eric Dumazet @ 2010-08-29 18:39 UTC (permalink / raw)
  To: David Miller; +Cc: jarkao2, shemminger, herbert, netdev

Le dimanche 29 août 2010 à 10:06 -0700, David Miller a écrit :
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Sun, 29 Aug 2010 11:59:51 +0200
> 
> > Actually, when GRO compares napi->dev to skb->dev?
> 
> Hmmm, I thought the code made a skb->dev comparison with the
> existing SKBs in the list when checking for same-flow matches.
> 
> It doesn't, probably based upon the assumption that a NAPI
> instance maps to a unique device, the very topic we're
> discussing right now :-/
> 
> 

It does the check, Stephen added it in the commit I mentioned to start
this thread.

With net-next-2.6 this now reads :



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-29 18:39                   ` Eric Dumazet
@ 2010-08-30  6:42                     ` Jarek Poplawski
  2010-08-30 15:57                       ` Stephen Hemminger
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-30  6:42 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, shemminger, herbert, netdev

On 2010-08-29 20:39, Eric Dumazet wrote:
> Le dimanche 29 aoĂťt 2010 Ă  10:06 -0700, David Miller a ĂŠcrit :
>> From: Jarek Poplawski <jarkao2@gmail.com>
>> Date: Sun, 29 Aug 2010 11:59:51 +0200
>>
>>> Actually, when GRO compares napi->dev to skb->dev?
>>
>> Hmmm, I thought the code made a skb->dev comparison with the
>> existing SKBs in the list when checking for same-flow matches.
>>
>> It doesn't, probably based upon the assumption that a NAPI
>> instance maps to a unique device, the very topic we're
>> discussing right now :-/
>>
>>
> 
> It does the check, Stephen added it in the commit I mentioned to start
> this thread.
> 
> With net-next-2.6 this now reads :
> 

Since Stephen didn't seem to miss this too much it seems quite obvious
to me this check should be removed.

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-30  6:42                     ` Jarek Poplawski
@ 2010-08-30 15:57                       ` Stephen Hemminger
  2010-08-30 16:50                         ` David Miller
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-30 15:57 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: Eric Dumazet, David Miller, herbert, netdev

On Mon, 30 Aug 2010 06:42:31 +0000
Jarek Poplawski <jarkao2@gmail.com> wrote:

> On 2010-08-29 20:39, Eric Dumazet wrote:
> > Le dimanche 29 aoĂťt 2010 Ă  10:06 -0700, David Miller a ĂŠcrit :
> >> From: Jarek Poplawski <jarkao2@gmail.com>
> >> Date: Sun, 29 Aug 2010 11:59:51 +0200
> >>
> >>> Actually, when GRO compares napi->dev to skb->dev?
> >>
> >> Hmmm, I thought the code made a skb->dev comparison with the
> >> existing SKBs in the list when checking for same-flow matches.
> >>
> >> It doesn't, probably based upon the assumption that a NAPI
> >> instance maps to a unique device, the very topic we're
> >> discussing right now :-/
> >>
> >>
> > 
> > It does the check, Stephen added it in the commit I mentioned to start
> > this thread.
> > 
> > With net-next-2.6 this now reads :
> > 
> 
> Since Stephen didn't seem to miss this too much it seems quite obvious
> to me this check should be removed.

No. I just don't use that system much, breaking code for
sake of one comparison is ridiculous. If you need to do some
performance wanking, go figure out why just loading netfilter
drops forwarding performance by 20%.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-30 15:57                       ` Stephen Hemminger
@ 2010-08-30 16:50                         ` David Miller
  2010-08-30 17:51                           ` [PATCH] sky2: don't do GRO on second port Stephen Hemminger
  2010-08-30 18:36                           ` [RFC] gro: Is it ok to share a single napi from several devs ? Jarek Poplawski
  0 siblings, 2 replies; 41+ messages in thread
From: David Miller @ 2010-08-30 16:50 UTC (permalink / raw)
  To: shemminger; +Cc: jarkao2, eric.dumazet, herbert, netdev

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 30 Aug 2010 08:57:21 -0700

> On Mon, 30 Aug 2010 06:42:31 +0000
> Jarek Poplawski <jarkao2@gmail.com> wrote:
> 
>> On 2010-08-29 20:39, Eric Dumazet wrote:
>> > Le dimanche 29 aoĂťt 2010 Ă  10:06 -0700, David Miller a ĂŠcrit :
>> >> From: Jarek Poplawski <jarkao2@gmail.com>
>> >> Date: Sun, 29 Aug 2010 11:59:51 +0200
>> >>
>> >>> Actually, when GRO compares napi->dev to skb->dev?
>> >>
>> >> Hmmm, I thought the code made a skb->dev comparison with the
>> >> existing SKBs in the list when checking for same-flow matches.
>> >>
>> >> It doesn't, probably based upon the assumption that a NAPI
>> >> instance maps to a unique device, the very topic we're
>> >> discussing right now :-/
>> >>
>> >>
>> > 
>> > It does the check, Stephen added it in the commit I mentioned to start
>> > this thread.
>> > 
>> > With net-next-2.6 this now reads :
>> > 
>> 
>> Since Stephen didn't seem to miss this too much it seems quite obvious
>> to me this check should be removed.
> 
> No. I just don't use that system much, breaking code for
> sake of one comparison is ridiculous.

It's not working to begin with.

I agree with Jarek that the check should be removed.  And GRO is one
of those places that, precisely, even one memory reference removal
can improve performance dramatically.

Herbert spent a lot of time doing micro-optimizations to make GRO
better and better, and the smallest things can turn out to make a huge
difference there.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PATCH] sky2: don't do GRO on second port
  2010-08-30 16:50                         ` David Miller
@ 2010-08-30 17:51                           ` Stephen Hemminger
  2010-08-30 19:09                             ` Jarek Poplawski
  2010-08-30 18:36                           ` [RFC] gro: Is it ok to share a single napi from several devs ? Jarek Poplawski
  1 sibling, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-30 17:51 UTC (permalink / raw)
  To: David Miller; +Cc: jarkao2, eric.dumazet, herbert, netdev


 There's something very important I forgot to tell you.
 What?

 Don't cross the GRO streams.
 Why?

 It would be bad.
 I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?

 Try to imagine all the Internet as you know it stopping instantaneously
  and every bit in every packet swapping at the speed of light.
 Total packet reordering.
 Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert

The simplest way to stop this is just avoid doing GRO on the second port.
Very few Marvell boards support two ports per ring, and GRO is just
an optimization.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


--- a/drivers/net/sky2.c	2010-08-30 10:13:28.211536096 -0700
+++ b/drivers/net/sky2.c	2010-08-30 10:22:01.347183151 -0700
@@ -2520,24 +2520,27 @@ static inline void sky2_tx_done(struct n
 	}
 }
 
-static inline void sky2_skb_rx(const struct sky2_port *sky2,
+static inline void sky2_skb_rx(struct napi_struct *napi,
+			       const struct sky2_port *sky2,
 			       u32 status, struct sk_buff *skb)
 {
 #ifdef SKY2_VLAN_TAG_USED
-	u16 vlan_tag = be16_to_cpu(sky2->rx_tag);
 	if (sky2->vlgrp && (status & GMR_FS_VLAN)) {
-		if (skb->ip_summed == CHECKSUM_NONE)
+		u16 vlan_tag = be16_to_cpu(sky2->rx_tag);
+
+		if (skb->ip_summed == CHECKSUM_NONE ||
+		    sky2->netdev != napi->dev)
 			vlan_hwaccel_receive_skb(skb, sky2->vlgrp, vlan_tag);
 		else
-			vlan_gro_receive(&sky2->hw->napi, sky2->vlgrp,
-					 vlan_tag, skb);
+			vlan_gro_receive(napi, sky2->vlgrp, vlan_tag, skb);
 		return;
 	}
 #endif
-	if (skb->ip_summed == CHECKSUM_NONE)
+	if (skb->ip_summed == CHECKSUM_NONE ||
+	    sky2->netdev != napi->dev)
 		netif_receive_skb(skb);
 	else
-		napi_gro_receive(&sky2->hw->napi, skb);
+		napi_gro_receive(napi, skb);
 }
 
 static inline void sky2_rx_done(struct sky2_hw *hw, unsigned port,
@@ -2638,7 +2641,7 @@ static int sky2_status_intr(struct sky2_
 
 			skb->protocol = eth_type_trans(skb, dev);
 
-			sky2_skb_rx(sky2, status, skb);
+			sky2_skb_rx(&hw->napi, sky2, status, skb);
 
 			/* Stop after net poll weight */
 			if (++work_done >= to_do)

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
  2010-08-30 16:50                         ` David Miller
  2010-08-30 17:51                           ` [PATCH] sky2: don't do GRO on second port Stephen Hemminger
@ 2010-08-30 18:36                           ` Jarek Poplawski
  2010-08-30 19:59                             ` [RFC] netpoll: " Eric Dumazet
  1 sibling, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-30 18:36 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, eric.dumazet, herbert, netdev

On Mon, Aug 30, 2010 at 09:50:12AM -0700, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 30 Aug 2010 08:57:21 -0700
> 
> > On Mon, 30 Aug 2010 06:42:31 +0000
> > Jarek Poplawski <jarkao2@gmail.com> wrote:
> > 
> >> On 2010-08-29 20:39, Eric Dumazet wrote:
> >> > Le dimanche 29 aoĂťt 2010 Ă  10:06 -0700, David Miller a ĂŠcrit :
> >> >> From: Jarek Poplawski <jarkao2@gmail.com>
> >> >> Date: Sun, 29 Aug 2010 11:59:51 +0200
> >> >>
> >> >>> Actually, when GRO compares napi->dev to skb->dev?
> >> >>
> >> >> Hmmm, I thought the code made a skb->dev comparison with the
> >> >> existing SKBs in the list when checking for same-flow matches.
> >> >>
> >> >> It doesn't, probably based upon the assumption that a NAPI
> >> >> instance maps to a unique device, the very topic we're
> >> >> discussing right now :-/
> >> >>
> >> >>
> >> > 
> >> > It does the check, Stephen added it in the commit I mentioned to start
> >> > this thread.
> >> > 
> >> > With net-next-2.6 this now reads :
> >> > 
> >> 
> >> Since Stephen didn't seem to miss this too much it seems quite obvious
> >> to me this check should be removed.
> > 
> > No. I just don't use that system much, breaking code for
> > sake of one comparison is ridiculous.
> 
> It's not working to begin with.

IMHO it should work yet. On the other hand, after removing this test
GRO should still work OK for these NICs in most cases, so it should be
treated as an optimization only. And it seems very unusual to keep such
optimizations at this level for such rare cases.

> I agree with Jarek that the check should be removed.  And GRO is one
> of those places that, precisely, even one memory reference removal
> can improve performance dramatically.

Hmm... I proposed removal when Stephen didn't defend it. Since he
seems to change his line, I'd prefer to be convinced I'm wrong,
preferably with some use/test case; most preferably from some
desperated user...

> Herbert spent a lot of time doing micro-optimizations to make GRO
> better and better, and the smallest things can turn out to make a huge
> difference there.

Anyway, after the last Eric's optimization, it's almost invisible...

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-08-30 17:51                           ` [PATCH] sky2: don't do GRO on second port Stephen Hemminger
@ 2010-08-30 19:09                             ` Jarek Poplawski
  2010-09-01 21:51                               ` David Miller
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-08-30 19:09 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, eric.dumazet, herbert, netdev

On Mon, Aug 30, 2010 at 10:51:17AM -0700, Stephen Hemminger wrote:
> 
>  There's something very important I forgot to tell you.
>  What?
> 
>  Don't cross the GRO streams.
>  Why?
> 
>  It would be bad.
>  I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
> 
>  Try to imagine all the Internet as you know it stopping instantaneously
>   and every bit in every packet swapping at the speed of light.
>  Total packet reordering.
>  Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert

Looks really bad to me, so... let's forget it! ;-) (At least until
next next.)

Jarek P.

> 
> The simplest way to stop this is just avoid doing GRO on the second port.
> Very few Marvell boards support two ports per ring, and GRO is just
> an optimization.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 
> 
> --- a/drivers/net/sky2.c	2010-08-30 10:13:28.211536096 -0700
> +++ b/drivers/net/sky2.c	2010-08-30 10:22:01.347183151 -0700
> @@ -2520,24 +2520,27 @@ static inline void sky2_tx_done(struct n
>  	}
>  }
>  
> -static inline void sky2_skb_rx(const struct sky2_port *sky2,
> +static inline void sky2_skb_rx(struct napi_struct *napi,
> +			       const struct sky2_port *sky2,
>  			       u32 status, struct sk_buff *skb)
>  {
>  #ifdef SKY2_VLAN_TAG_USED
> -	u16 vlan_tag = be16_to_cpu(sky2->rx_tag);
>  	if (sky2->vlgrp && (status & GMR_FS_VLAN)) {
> -		if (skb->ip_summed == CHECKSUM_NONE)
> +		u16 vlan_tag = be16_to_cpu(sky2->rx_tag);
> +
> +		if (skb->ip_summed == CHECKSUM_NONE ||
> +		    sky2->netdev != napi->dev)
>  			vlan_hwaccel_receive_skb(skb, sky2->vlgrp, vlan_tag);
>  		else
> -			vlan_gro_receive(&sky2->hw->napi, sky2->vlgrp,
> -					 vlan_tag, skb);
> +			vlan_gro_receive(napi, sky2->vlgrp, vlan_tag, skb);
>  		return;
>  	}
>  #endif
> -	if (skb->ip_summed == CHECKSUM_NONE)
> +	if (skb->ip_summed == CHECKSUM_NONE ||
> +	    sky2->netdev != napi->dev)
>  		netif_receive_skb(skb);
>  	else
> -		napi_gro_receive(&sky2->hw->napi, skb);
> +		napi_gro_receive(napi, skb);
>  }
>  
>  static inline void sky2_rx_done(struct sky2_hw *hw, unsigned port,
> @@ -2638,7 +2641,7 @@ static int sky2_status_intr(struct sky2_
>  
>  			skb->protocol = eth_type_trans(skb, dev);
>  
> -			sky2_skb_rx(sky2, status, skb);
> +			sky2_skb_rx(&hw->napi, sky2, status, skb);
>  
>  			/* Stop after net poll weight */
>  			if (++work_done >= to_do)

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [RFC] netpoll: Is it ok to share a single napi from several devs ?
  2010-08-30 18:36                           ` [RFC] gro: Is it ok to share a single napi from several devs ? Jarek Poplawski
@ 2010-08-30 19:59                             ` Eric Dumazet
  2010-08-30 20:12                               ` Stephen Hemminger
  0 siblings, 1 reply; 41+ messages in thread
From: Eric Dumazet @ 2010-08-30 19:59 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: David Miller, shemminger, herbert, netdev

So everybody jumped on GRO, while my concern was more the napi->dev
thing.

I pointed to gro because the commit was about gro, but gro was fine
IMHO.

Are we sure netpoll is ok ?

If a napi is shared by several net_device, should'nt we change
netpoll_poll_lock() ?

static inline void *netpoll_poll_lock(struct napi_struct *napi)
{
        struct net_device *dev = napi->dev;

        if (dev && dev->npinfo) {
                spin_lock(&napi->poll_lock);
                napi->poll_owner = smp_processor_id();
                return napi;
        }
        return NULL;
}

---->

static inline void *netpoll_poll_lock(struct napi_struct *napi)
{
        if (atomic_read(&napi->poll_count)) {
                spin_lock(&napi->poll_lock);
                napi->poll_owner = smp_processor_id();
                return napi;
        }
        return NULL;
}




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] netpoll: Is it ok to share a single napi from several devs ?
  2010-08-30 19:59                             ` [RFC] netpoll: " Eric Dumazet
@ 2010-08-30 20:12                               ` Stephen Hemminger
  2010-08-30 20:19                                 ` Eric Dumazet
  0 siblings, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-30 20:12 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Jarek Poplawski, David Miller, herbert, netdev

On Mon, 30 Aug 2010 21:59:16 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> So everybody jumped on GRO, while my concern was more the napi->dev
> thing.
> 
> I pointed to gro because the commit was about gro, but gro was fine
> IMHO.
> 
> Are we sure netpoll is ok ?

Netpoll is dependent on napi->netdev but does not cause problems.
The sky2 driver doesn't expose netpoll on second port.
The second port has different net_device_ops without netpoll.


-- 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] netpoll: Is it ok to share a single napi from several devs ?
  2010-08-30 20:12                               ` Stephen Hemminger
@ 2010-08-30 20:19                                 ` Eric Dumazet
  0 siblings, 0 replies; 41+ messages in thread
From: Eric Dumazet @ 2010-08-30 20:19 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Jarek Poplawski, David Miller, herbert, netdev

Le lundi 30 août 2010 à 13:12 -0700, Stephen Hemminger a écrit :
> On Mon, 30 Aug 2010 21:59:16 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> > So everybody jumped on GRO, while my concern was more the napi->dev
> > thing.
> > 
> > I pointed to gro because the commit was about gro, but gro was fine
> > IMHO.
> > 
> > Are we sure netpoll is ok ?
> 
> Netpoll is dependent on napi->netdev but does not cause problems.
> The sky2 driver doesn't expose netpoll on second port.
> The second port has different net_device_ops without netpoll.
> 
> 

Ah, great, thanks for clarification.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-08-30 19:09                             ` Jarek Poplawski
@ 2010-09-01 21:51                               ` David Miller
  2010-09-01 21:55                                 ` Stephen Hemminger
  2010-09-02  8:33                                 ` Jarek Poplawski
  0 siblings, 2 replies; 41+ messages in thread
From: David Miller @ 2010-09-01 21:51 UTC (permalink / raw)
  To: jarkao2; +Cc: shemminger, eric.dumazet, herbert, netdev

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 30 Aug 2010 21:09:00 +0200

> On Mon, Aug 30, 2010 at 10:51:17AM -0700, Stephen Hemminger wrote:
>> 
>>  There's something very important I forgot to tell you.
>>  What?
>> 
>>  Don't cross the GRO streams.
>>  Why?
>> 
>>  It would be bad.
>>  I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
>> 
>>  Try to imagine all the Internet as you know it stopping instantaneously
>>   and every bit in every packet swapping at the speed of light.
>>  Total packet reordering.
>>  Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert
> 
> Looks really bad to me, so... let's forget it! ;-) (At least until
> next next.)

I'm applying this patch.

Note that for us, devices act as domains, or a key for networking
traffic, whether we like it or not.  Yes, even for the same IP
addresses on the same host.

The reason is that we can do ingress packet editing and the realm of
those rules are per-ingress-qdisc, which are per-device.

The only scenerio you can guarentee that all packets for a given
flow key will be treated the same is the one where the input device
is the same as well.

When there is a single napi --> device mapping, it works, but without
that invariant it doesn't.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-01 21:51                               ` David Miller
@ 2010-09-01 21:55                                 ` Stephen Hemminger
  2010-09-02  9:18                                   ` Jarek Poplawski
  2010-09-02  8:33                                 ` Jarek Poplawski
  1 sibling, 1 reply; 41+ messages in thread
From: Stephen Hemminger @ 2010-09-01 21:55 UTC (permalink / raw)
  To: jarkao2; +Cc: David Miller, eric.dumazet, herbert, netdev

On Wed, 01 Sep 2010 14:51:51 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Mon, 30 Aug 2010 21:09:00 +0200
> 
> > On Mon, Aug 30, 2010 at 10:51:17AM -0700, Stephen Hemminger wrote:
> >> 
> >>  There's something very important I forgot to tell you.
> >>  What?
> >> 
> >>  Don't cross the GRO streams.
> >>  Why?
> >> 
> >>  It would be bad.
> >>  I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
> >> 
> >>  Try to imagine all the Internet as you know it stopping instantaneously
> >>   and every bit in every packet swapping at the speed of light.
> >>  Total packet reordering.
> >>  Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert
> > 
> > Looks really bad to me, so... let's forget it! ;-) (At least until
> > next next.)

The patch wasn't that bad, but the movie quote probably confused you.

Alternatively, the driver could keep track of "current GRO device"
and manually complete the GRO if the next packet changes
the current device.  But it didn't seem worth the effort.

-- 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-01 21:51                               ` David Miller
  2010-09-01 21:55                                 ` Stephen Hemminger
@ 2010-09-02  8:33                                 ` Jarek Poplawski
  2010-09-02  9:31                                   ` Eric Dumazet
  2010-09-02  9:32                                   ` Jarek Poplawski
  1 sibling, 2 replies; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02  8:33 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, eric.dumazet, herbert, netdev

On Wed, Sep 01, 2010 at 02:51:51PM -0700, David Miller wrote:
> The only scenerio you can guarentee that all packets for a given
> flow key will be treated the same is the one where the input device
> is the same as well.
> 
> When there is a single napi --> device mapping, it works, but without
> that invariant it doesn't.

Do you mean a single napi can't be used eg. for vlan_gro and napi_gro?
(napi_gro handles flows for skb->dev different from napi->dev or I
miss something?)

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-01 21:55                                 ` Stephen Hemminger
@ 2010-09-02  9:18                                   ` Jarek Poplawski
  2010-09-02 12:53                                     ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02  9:18 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, eric.dumazet, herbert, netdev

On Wed, Sep 01, 2010 at 02:55:54PM -0700, Stephen Hemminger wrote:
> On Wed, 01 Sep 2010 14:51:51 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Jarek Poplawski <jarkao2@gmail.com>
> > Date: Mon, 30 Aug 2010 21:09:00 +0200
> > 
> > > On Mon, Aug 30, 2010 at 10:51:17AM -0700, Stephen Hemminger wrote:
> > >> 
> > >>  There's something very important I forgot to tell you.
> > >>  What?
> > >> 
> > >>  Don't cross the GRO streams.
> > >>  Why?
> > >> 
> > >>  It would be bad.
> > >>  I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
> > >> 
> > >>  Try to imagine all the Internet as you know it stopping instantaneously
> > >>   and every bit in every packet swapping at the speed of light.
> > >>  Total packet reordering.
> > >>  Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert
> > > 
> > > Looks really bad to me, so... let's forget it! ;-) (At least until
> > > next next.)
> 
> The patch wasn't that bad, but the movie quote probably confused you.

Yes, I was equally confused by both of them. Good to know it's only
fiction... ;-)

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02  8:33                                 ` Jarek Poplawski
@ 2010-09-02  9:31                                   ` Eric Dumazet
  2010-09-02  9:55                                     ` Jarek Poplawski
  2010-09-02  9:32                                   ` Jarek Poplawski
  1 sibling, 1 reply; 41+ messages in thread
From: Eric Dumazet @ 2010-09-02  9:31 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: David Miller, shemminger, herbert, netdev

Le jeudi 02 septembre 2010 à 08:33 +0000, Jarek Poplawski a écrit :
> On Wed, Sep 01, 2010 at 02:51:51PM -0700, David Miller wrote:
> > The only scenerio you can guarentee that all packets for a given
> > flow key will be treated the same is the one where the input device
> > is the same as well.
> > 
> > When there is a single napi --> device mapping, it works, but without
> > that invariant it doesn't.
> 
> Do you mean a single napi can't be used eg. for vlan_gro and napi_gro?
> (napi_gro handles flows for skb->dev different from napi->dev or I
> miss something?)
> 

Same napi can be used both for vlan tagged trafic and "non tagged
trafic".

vlan_gro_common() does the right thing, when initializing skb->dev to
the vlan device, before doing the GRO loop.

So if we receive two packets on same ethernet device, two different
vlans, vlan_gro_common() automatically say they are not part of the same
flow, even if upper layers would say "it's ok for these two packets to
merge". Of course, we wont ask upper layers what they think :)

So we must keep the test against skb->dev, because of vlans,

diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;

(both in vlan_gro_common() and __napi_gro_receive())



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02  8:33                                 ` Jarek Poplawski
  2010-09-02  9:31                                   ` Eric Dumazet
@ 2010-09-02  9:32                                   ` Jarek Poplawski
  1 sibling, 0 replies; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02  9:32 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, eric.dumazet, herbert, netdev

On Thu, Sep 02, 2010 at 08:33:27AM +0000, Jarek Poplawski wrote:
> On Wed, Sep 01, 2010 at 02:51:51PM -0700, David Miller wrote:
> > The only scenerio you can guarentee that all packets for a given
> > flow key will be treated the same is the one where the input device
> > is the same as well.
> > 
> > When there is a single napi --> device mapping, it works, but without
> > that invariant it doesn't.
> 
> Do you mean a single napi can't be used eg. for vlan_gro and napi_gro?
> (napi_gro handles flows for skb->dev different from napi->dev or I
Of course I meant:
(vlan_gro handles flows for skb->dev different from napi->dev or I

> miss something?)

Sorry,
Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02  9:31                                   ` Eric Dumazet
@ 2010-09-02  9:55                                     ` Jarek Poplawski
  2010-09-02 10:41                                       ` Eric Dumazet
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02  9:55 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, shemminger, herbert, netdev

On Thu, Sep 02, 2010 at 11:31:49AM +0200, Eric Dumazet wrote:
> Le jeudi 02 septembre 2010 ?? 08:33 +0000, Jarek Poplawski a écrit :
> > On Wed, Sep 01, 2010 at 02:51:51PM -0700, David Miller wrote:
> > > The only scenerio you can guarentee that all packets for a given
> > > flow key will be treated the same is the one where the input device
> > > is the same as well.
> > > 
> > > When there is a single napi --> device mapping, it works, but without
> > > that invariant it doesn't.
> > 
> > Do you mean a single napi can't be used eg. for vlan_gro and napi_gro?
> > (napi_gro handles flows for skb->dev different from napi->dev or I
> > miss something?)
> > 
> 
> Same napi can be used both for vlan tagged trafic and "non tagged
> trafic".
> 
> vlan_gro_common() does the right thing, when initializing skb->dev to
> the vlan device, before doing the GRO loop.
> 
> So if we receive two packets on same ethernet device, two different
> vlans, vlan_gro_common() automatically say they are not part of the same
> flow, even if upper layers would say "it's ok for these two packets to
> merge". Of course, we wont ask upper layers what they think :)
> 
> So we must keep the test against skb->dev, because of vlans,
> 
> diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
> 
> (both in vlan_gro_common() and __napi_gro_receive())
> 

Exactly, but there is no "a single napi --> device mapping". And sky2
uses the same model. So, there is only a question of cost of this test,
and a question of probability of gro errors on collisions without such
a test in normal use. (And if gro can never do such errors for other
reasons?)

Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02  9:55                                     ` Jarek Poplawski
@ 2010-09-02 10:41                                       ` Eric Dumazet
  2010-09-02 11:02                                         ` Jarek Poplawski
                                                           ` (2 more replies)
  0 siblings, 3 replies; 41+ messages in thread
From: Eric Dumazet @ 2010-09-02 10:41 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: David Miller, shemminger, herbert, netdev

Le jeudi 02 septembre 2010 à 09:55 +0000, Jarek Poplawski a écrit :

> 
> Exactly, but there is no "a single napi --> device mapping". And sky2
> uses the same model. So, there is only a question of cost of this test,
> and a question of probability of gro errors on collisions without such
> a test in normal use. (And if gro can never do such errors for other
> reasons?)

Two vlans might carry packets in different domains, with a clash of IP
space and TCP flows. Even with a probability of 0.000000001%, we cannot
ever merge two packets of different domains. Really !

napi->dev is not used in GRO path, as mentioned earlier,
but in napi_get_frags(), while not needed.

To make this very clear, I suggest following patch :

[PATCH net-next-2.6] gro: remove use of napi->dev

Only use of napi->dev in GRO stack is the one found in napi_get_frags()

We can remove it and use a plain dev_alloc_skb() call.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/core/dev.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d8c43e7..607057a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3248,9 +3248,11 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
 	struct sk_buff *skb = napi->skb;
 
 	if (!skb) {
-		skb = netdev_alloc_skb_ip_align(napi->dev, GRO_MAX_HEAD);
-		if (skb)
+		skb = dev_alloc_skb(GRO_MAX_HEAD + NET_IP_ALIGN);
+		if (skb) {
+			skb_reserve(skb, NET_IP_ALIGN);
 			napi->skb = skb;
+		}
 	}
 	return skb;
 }



^ permalink raw reply related	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 10:41                                       ` Eric Dumazet
@ 2010-09-02 11:02                                         ` Jarek Poplawski
  2010-09-02 12:09                                           ` Eric Dumazet
  2010-09-02 17:08                                         ` David Miller
  2010-09-02 21:26                                         ` Herbert Xu
  2 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02 11:02 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, shemminger, herbert, netdev

On Thu, Sep 02, 2010 at 12:41:45PM +0200, Eric Dumazet wrote:
> Le jeudi 02 septembre 2010 ?? 09:55 +0000, Jarek Poplawski a écrit :
> 
> > 
> > Exactly, but there is no "a single napi --> device mapping". And sky2
> > uses the same model. So, there is only a question of cost of this test,
> > and a question of probability of gro errors on collisions without such
> > a test in normal use. (And if gro can never do such errors for other
> > reasons?)
> 
> Two vlans might carry packets in different domains, with a clash of IP
> space and TCP flows. Even with a probability of 0.000000001%, we cannot
> ever merge two packets of different domains. Really !

Hmm... But there is only a question of sky2 and this test in
__napi_gro_receive().

> 
> napi->dev is not used in GRO path, as mentioned earlier,
> but in napi_get_frags(), while not needed.
> 
> To make this very clear, I suggest following patch :

But where this skb gets its skb->dev now?

Jarek P.

> 
> [PATCH net-next-2.6] gro: remove use of napi->dev
> 
> Only use of napi->dev in GRO stack is the one found in napi_get_frags()
> 
> We can remove it and use a plain dev_alloc_skb() call.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  net/core/dev.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index d8c43e7..607057a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3248,9 +3248,11 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
>  	struct sk_buff *skb = napi->skb;
>  
>  	if (!skb) {
> -		skb = netdev_alloc_skb_ip_align(napi->dev, GRO_MAX_HEAD);
> -		if (skb)
> +		skb = dev_alloc_skb(GRO_MAX_HEAD + NET_IP_ALIGN);
> +		if (skb) {
> +			skb_reserve(skb, NET_IP_ALIGN);
>  			napi->skb = skb;
> +		}
>  	}
>  	return skb;
>  }
> 
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 11:02                                         ` Jarek Poplawski
@ 2010-09-02 12:09                                           ` Eric Dumazet
  2010-09-02 12:28                                             ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: Eric Dumazet @ 2010-09-02 12:09 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: David Miller, shemminger, herbert, netdev

Le jeudi 02 septembre 2010 à 11:02 +0000, Jarek Poplawski a écrit :
> On Thu, Sep 02, 2010 at 12:41:45PM +0200, Eric Dumazet wrote:

> > Two vlans might carry packets in different domains, with a clash of IP
> > space and TCP flows. Even with a probability of 0.000000001%, we cannot
> > ever merge two packets of different domains. Really !
> 
> Hmm... But there is only a question of sky2 and this test in
> __napi_gro_receive().
> 

Any driver can receive in one napi run :

1) A TCP tagged frame for vlan 345, delivered to vlan_gro_receive(),
queued in napi->gro_list.

2) An untagged frame, delived via napi_gro_receive()
    Can meet previous frame in napi->gro_list. Should not merge.

So napi_gro_receive() must perform the same skb->dev check, sky2 or not.

> > 
> > napi->dev is not used in GRO path, as mentioned earlier,
> > but in napi_get_frags(), while not needed.
> > 
> > To make this very clear, I suggest following patch :
> 
> But where this skb gets its skb->dev now?

Oh you are right, I thought drivers were setting this later, but its not
the case.




^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 12:09                                           ` Eric Dumazet
@ 2010-09-02 12:28                                             ` Jarek Poplawski
  0 siblings, 0 replies; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02 12:28 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, shemminger, herbert, netdev

On Thu, Sep 02, 2010 at 02:09:09PM +0200, Eric Dumazet wrote:
> Le jeudi 02 septembre 2010 ?? 11:02 +0000, Jarek Poplawski a écrit :
> > On Thu, Sep 02, 2010 at 12:41:45PM +0200, Eric Dumazet wrote:
> 
> > > Two vlans might carry packets in different domains, with a clash of IP
> > > space and TCP flows. Even with a probability of 0.000000001%, we cannot
> > > ever merge two packets of different domains. Really !
> > 
> > Hmm... But there is only a question of sky2 and this test in
> > __napi_gro_receive().
> > 
> 
> Any driver can receive in one napi run :
> 
> 1) A TCP tagged frame for vlan 345, delivered to vlan_gro_receive(),
> queued in napi->gro_list.
> 
> 2) An untagged frame, delived via napi_gro_receive()
>     Can meet previous frame in napi->gro_list. Should not merge.
> 
> So napi_gro_receive() must perform the same skb->dev check, sky2 or not.

But of course!!! I was mislead by Stephen's changelog so much. So now
I really can't understand this current: "sky2: don't do GRO on second
port"...

Thanks,
Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02  9:18                                   ` Jarek Poplawski
@ 2010-09-02 12:53                                     ` Jarek Poplawski
  2010-09-02 16:30                                       ` David Miller
  0 siblings, 1 reply; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02 12:53 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, eric.dumazet, herbert, netdev

On Thu, Sep 02, 2010 at 09:18:39AM +0000, Jarek Poplawski wrote:
> On Wed, Sep 01, 2010 at 02:55:54PM -0700, Stephen Hemminger wrote:
> > On Wed, 01 Sep 2010 14:51:51 -0700 (PDT)
> > David Miller <davem@davemloft.net> wrote:
> > 
> > > From: Jarek Poplawski <jarkao2@gmail.com>
> > > Date: Mon, 30 Aug 2010 21:09:00 +0200
> > > 
> > > > On Mon, Aug 30, 2010 at 10:51:17AM -0700, Stephen Hemminger wrote:
> > > >> 
> > > >>  There's something very important I forgot to tell you.
> > > >>  What?
> > > >> 
> > > >>  Don't cross the GRO streams.
> > > >>  Why?
> > > >> 
> > > >>  It would be bad.
> > > >>  I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
> > > >> 
> > > >>  Try to imagine all the Internet as you know it stopping instantaneously
> > > >>   and every bit in every packet swapping at the speed of light.
> > > >>  Total packet reordering.
> > > >>  Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert
> > > > 
> > > > Looks really bad to me, so... let's forget it! ;-) (At least until
> > > > next next.)
> > 
> > The patch wasn't that bad, but the movie quote probably confused you.
> 
> Yes, I was equally confused by both of them. Good to know it's only
> fiction... ;-)

Stephen, after Eric's explanation, I really think this patch was a bad
idea, and I apologize my false opinion started this.

I hope David, will revert this patch, please.

Sorry,
Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 12:53                                     ` Jarek Poplawski
@ 2010-09-02 16:30                                       ` David Miller
  2010-09-02 16:48                                         ` Jarek Poplawski
  0 siblings, 1 reply; 41+ messages in thread
From: David Miller @ 2010-09-02 16:30 UTC (permalink / raw)
  To: jarkao2; +Cc: shemminger, eric.dumazet, herbert, netdev

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Thu, 2 Sep 2010 12:53:26 +0000

> Stephen, after Eric's explanation, I really think this patch was a bad
> idea, and I apologize my false opinion started this.
> 
> I hope David, will revert this patch, please.

Ok, now that I've reread everything over I agree, I'll revert the
sky2 change, thanks.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 16:30                                       ` David Miller
@ 2010-09-02 16:48                                         ` Jarek Poplawski
  0 siblings, 0 replies; 41+ messages in thread
From: Jarek Poplawski @ 2010-09-02 16:48 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, eric.dumazet, herbert, netdev

On Thu, Sep 02, 2010 at 09:30:23AM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Thu, 2 Sep 2010 12:53:26 +0000
> 
> > Stephen, after Eric's explanation, I really think this patch was a bad
> > idea, and I apologize my false opinion started this.
> > 
> > I hope David, will revert this patch, please.
> 
> Ok, now that I've reread everything over I agree, I'll revert the
> sky2 change, thanks.

Thanks!
Jarek P.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 10:41                                       ` Eric Dumazet
  2010-09-02 11:02                                         ` Jarek Poplawski
@ 2010-09-02 17:08                                         ` David Miller
  2010-09-02 21:26                                         ` Herbert Xu
  2 siblings, 0 replies; 41+ messages in thread
From: David Miller @ 2010-09-02 17:08 UTC (permalink / raw)
  To: eric.dumazet; +Cc: jarkao2, shemminger, herbert, netdev

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 02 Sep 2010 12:41:45 +0200

> [PATCH net-next-2.6] gro: remove use of napi->dev
> 
> Only use of napi->dev in GRO stack is the one found in napi_get_frags()
> 
> We can remove it and use a plain dev_alloc_skb() call.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

If you change this to use skb->dev I can apply this.

Thanks.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 10:41                                       ` Eric Dumazet
  2010-09-02 11:02                                         ` Jarek Poplawski
  2010-09-02 17:08                                         ` David Miller
@ 2010-09-02 21:26                                         ` Herbert Xu
  2010-09-03  5:23                                           ` Eric Dumazet
  2 siblings, 1 reply; 41+ messages in thread
From: Herbert Xu @ 2010-09-02 21:26 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Jarek Poplawski, David Miller, shemminger, netdev

On Thu, Sep 02, 2010 at 12:41:45PM +0200, Eric Dumazet wrote:
> 
> [PATCH net-next-2.6] gro: remove use of napi->dev
> 
> Only use of napi->dev in GRO stack is the one found in napi_get_frags()
> 
> We can remove it and use a plain dev_alloc_skb() call.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Why do you think napi->dev is not needed?
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH] sky2: don't do GRO on second port
  2010-09-02 21:26                                         ` Herbert Xu
@ 2010-09-03  5:23                                           ` Eric Dumazet
  0 siblings, 0 replies; 41+ messages in thread
From: Eric Dumazet @ 2010-09-03  5:23 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Jarek Poplawski, David Miller, shemminger, netdev

Le vendredi 03 septembre 2010 à 05:26 +0800, Herbert Xu a écrit :
> On Thu, Sep 02, 2010 at 12:41:45PM +0200, Eric Dumazet wrote:
> > 
> > [PATCH net-next-2.6] gro: remove use of napi->dev
> > 
> > Only use of napi->dev in GRO stack is the one found in napi_get_frags()
> > 
> > We can remove it and use a plain dev_alloc_skb() call.
> > 
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> 
> Why do you think napi->dev is not needed?

Origin was that sky2 could use one napi and two devices on it.
No bug, only a conceptual problem using a napi->dev.

Then, there is a small second point :

netdev_alloc_skb_ip_align() is using 'device' NUMA node to allocate
memory.

In this context, this makes litle sense because this skb is not going to
be used by the device. Its a pure software one, for the sake of GRO
handling.

It would be more efficient to allocate an skb on NUMA node of the CPU
handling the softirq.

Thanks



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [RFC] gro: Is it ok to share a single napi from several devs ?
@ 2010-08-29  4:07 Stephen Hemminger
  0 siblings, 0 replies; 41+ messages in thread
From: Stephen Hemminger @ 2010-08-29  4:07 UTC (permalink / raw)
  To: David Miller, shemminger; +Cc: eric.dumazet, jarkao2, herbert, netdev

I am not really worried. about sky2 dual port since the dual port boards are rare. I might have one of the few in use 

David Miller <davem@davemloft.net> wrote:

>From: Stephen Hemminger <shemminger@vyatta.com>
>Date: Sat, 28 Aug 2010 15:31:24 -0700
>
>> On Sat, 28 Aug 2010 14:41:30 -0700 (PDT)
>> David Miller <davem@davemloft.net> wrote:
>> 
>>> Since netpoll does similar things, this means both NAPI and netpoll
>>> cannot function properly with SKY2's second port.  It will only work
>>> right on the first port.
>> 
>> I knew netpoll was broken on second port.
>
>Well, now we know that GRO is too :-)
>
>If we wish to keep the one-to-one mapping of NAPI contexts to
>interrupt sources, what we can do is provide some kind of "dev list".
>
>The other option is to register two NAPI contexts and schedule them
>both on an interrupt.
>
>But in both cases, detecting the end of polling, and thus when to turn
>the interrupts back on, is non-trivial.
>
>I really don't like either solution, therefore, so I'll try to brain
>storm on this a bit more.

^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2010-09-03  5:30 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-27 20:50 [PATCH] net: Fix vlan_gro_frags vs netpoll and bonding paths Jarek Poplawski
2010-08-28  0:13 ` Herbert Xu
2010-08-28  9:44   ` Jarek Poplawski
2010-08-28 10:54     ` [RFC] gro: Is it ok to share a single napi from several devs ? Eric Dumazet
2010-08-28 14:31       ` Jarek Poplawski
2010-08-28 14:48         ` Eric Dumazet
2010-08-28 15:16           ` Jarek Poplawski
2010-08-28 17:14           ` Stephen Hemminger
2010-08-28 21:41             ` David Miller
2010-08-28 22:31               ` Stephen Hemminger
2010-08-28 22:33                 ` David Miller
2010-08-29  9:59               ` Jarek Poplawski
2010-08-29 17:06                 ` David Miller
2010-08-29 18:39                   ` Eric Dumazet
2010-08-30  6:42                     ` Jarek Poplawski
2010-08-30 15:57                       ` Stephen Hemminger
2010-08-30 16:50                         ` David Miller
2010-08-30 17:51                           ` [PATCH] sky2: don't do GRO on second port Stephen Hemminger
2010-08-30 19:09                             ` Jarek Poplawski
2010-09-01 21:51                               ` David Miller
2010-09-01 21:55                                 ` Stephen Hemminger
2010-09-02  9:18                                   ` Jarek Poplawski
2010-09-02 12:53                                     ` Jarek Poplawski
2010-09-02 16:30                                       ` David Miller
2010-09-02 16:48                                         ` Jarek Poplawski
2010-09-02  8:33                                 ` Jarek Poplawski
2010-09-02  9:31                                   ` Eric Dumazet
2010-09-02  9:55                                     ` Jarek Poplawski
2010-09-02 10:41                                       ` Eric Dumazet
2010-09-02 11:02                                         ` Jarek Poplawski
2010-09-02 12:09                                           ` Eric Dumazet
2010-09-02 12:28                                             ` Jarek Poplawski
2010-09-02 17:08                                         ` David Miller
2010-09-02 21:26                                         ` Herbert Xu
2010-09-03  5:23                                           ` Eric Dumazet
2010-09-02  9:32                                   ` Jarek Poplawski
2010-08-30 18:36                           ` [RFC] gro: Is it ok to share a single napi from several devs ? Jarek Poplawski
2010-08-30 19:59                             ` [RFC] netpoll: " Eric Dumazet
2010-08-30 20:12                               ` Stephen Hemminger
2010-08-30 20:19                                 ` Eric Dumazet
2010-08-29  4:07 [RFC] gro: " Stephen Hemminger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.