netdev - Re: [PATCH] NIU support for skb->rxhash

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: <20100423.011456.48472321.davem@davemloft.net>
Date:	Fri, 23 Apr 2010 01:14:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] NIU support for skb->rxhash

From: David Miller <davem@...emloft.net>
Date: Thu, 22 Apr 2010 14:19:22 -0700 (PDT)

> Also I have some ideas about what we can do if we have
> just the rxhash.  It seems we can avoid the type_trans
> overhead on the interrupting cpu.
> 
> Things like eth_type_trans() become a netdev operation rather than
> something drivers statically call by hand. ->ndo_type_trans or
> similar.
> 
> SKB has a state bit saying whether ->ndo_type_trans has been invoked
> yet on RX.
> 
> Drivers pass raw SKBs up into the stack.
> 
> We defer the ->ndo_type_trans as far as possible, for RPS when we have
> ->rxhash we can defer this all the way to the destination RPS cpu.
> 
> If we lack ->rxhash, the source cpu will need to invoke
> ->ndo_type_trans before it can begin parsing the packet.

I looked into implementing this and it doesn't work.  The
problem is GRO want's to look into the packet very early
and we want to batch GRO a set of packets into a big packet
before shooting them over to a remote cpu.

This reminds me that we can start using ->rxhash as a quick
mismatch check in the GRO flow matcher.
--
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