netdev - Re: [PATCH] net: Check skb->rxhash in gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+mtBx_c=we-13b0Vyrim0=kArhx0OYY1P99HwUeuR2w87hRFw@mail.gmail.com>
Date:	Fri, 10 Jan 2014 08:27:20 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: Check skb->rxhash in gro_receive

On Thu, Jan 9, 2014 at 9:38 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Thu, 2014-01-09 at 20:54 -0800, Tom Herbert wrote:
>> When initializing a gro_list for a packet, first check the rxhash of
>> the incoming skb against that of the skb's in the list. This should be
>> a very strong inidicator of whether the flow is going to be matched,
>> and potentially allows a lot of other checks to be short circuited.
>>
>
> Hmm... this idea was discussed in the past. I used it when attempting to
> use a hash table instead of a gro_list last year.
>
> Unfortunately this added lot of cycles when rxhash is not provided by
> hardware, and my tests found it was not a win.
>
> Remember : in most cases, gro_list contains one flow, so this test does
> nothing special but adds overhead.

I don't understand what your basis is that gro_list in most cases
contains one flow, but assuming that were true, maybe we should make
the it only contain one flow eliminating the complexity of multiple
flows (same_flow logic is convoluted and layers of encapsulation is
not going to simplify things).

If we are doing RPS or RFS, rxhash will be computed anyway, so the
case your optimizing is pretty narrow: no RPS, no RFS, no hardware
hash, and a single flow in gro_list. Nevertheless, if this is really
an important concern, we can make the check directly against
skb->rxhash so to be opportunistic and avoid the possibility of
computation.

>
>
>
--
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