[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363294743.2695.10.camel@bwh-desktop.uk.solarflarecom.com>
Date: Thu, 14 Mar 2013 20:59:03 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Jesper Dangaard Brouer <jbrouer@...hat.com>
CC: Eric Dumazet <eric.dumazet@...il.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
<netdev@...r.kernel.org>, <yoshfuji@...ux-ipv6.org>
Subject: Re: RFC crap-patch [PATCH] net: Per CPU separate frag mem accounting
On Thu, 2013-03-14 at 09:59 +0100, Jesper Dangaard Brouer wrote:
> On Thu, 2013-03-14 at 08:25 +0100, Jesper Dangaard Brouer wrote:
> > This is NOT the patch I just mentioned in the other thread, of removing
> > the LRU list. This patch does real per cpu mem acct, and LRU per CPU.
> >
> > I get really good performance number with this patch, but I still think
> > this might not be the correct solution.
>
> The reason is this depend on fragments entering the same HW queue, some
> NICs might not put the first fragment (which have the full header
> tuples) and the remaining fragments on the same queue. In which case
> this patch will loose its performance gain.
[...]
The Microsoft RSS spec only includes port numbers in the flow hash for
TCP, presumably because TCP avoids IP fragmentation whereas datagram
protocols cannot. Some Linux drivers allow UDP ports to be included in
the flow hash but I don't think this is the default for any of them.
In Solarflare hardware the IPv4 MF bit inhibits layer 4 flow steering,
so all fragments will be unsteered. I don't know whether everyone else
got that right though. :-)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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