[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1412143934.16704.36.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 30 Sep 2014 23:12:14 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Tom Herbert <therbert@...gle.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
Or Gerlitz <gerlitz.or@...il.com>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
David Miller <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
Thomas Graf <tgraf@...g.ch>,
Pravin Shelar <pshelar@...ira.com>,
John Fastabend <john.r.fastabend@...el.com>,
Andy Zhou <azhou@...ira.com>
Subject: Re: [PATCH] net: Add ndo_gso_check
On Tue, 2014-09-30 at 17:18 -0700, Eric Dumazet wrote:
> On Tue, 2014-09-30 at 17:05 -0700, Tom Herbert wrote:
>
> >
> > Will this still be an advantage with the burst TX implementation?
>
> Segmenting a 64K packet into 45 sk_buff adds an additional 90
> allocations (45 sk_buff, 45 sk->head) and dirtying a _lot_ of memory.
>
> We now have some helpers that might be used by drivers to perform TSO
> emulation.
>
> commit e876f208af18b074f800656e4d1b99da75b2135f ("net: Add a software
> TSO helper API")
>
> Check commit 3ae8f4e0b98b640aadf410c21185ccb6b5b02351 for reference
> ("net: mv643xx_eth: Implement software TSO")
BTW, even for NIC TSO capable, it seems TSO can be slower for small
packets (like 2 MSS packets) on some NICs at least...
In this case forcing segmentation can be a win (consumes more cpu
cycles, but reduce the stress on the NIC)
(Adding an extra check in netif_skb_features() would do as well, I
suppose)
+ if (skb_shinfo(skb)->gso_segs < skb->dev->gso_min_segs)
+ features &= ~NETIF_F_GSO_MASK;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists