On Mon, Jan 18, 2016 at 6:24 PM, David Miller <da...@davemloft.net> wrote: > From: Jesper Dangaard Brouer <bro...@redhat.com> > Date: Mon, 18 Jan 2016 11:27:03 +0100 > >> Down in the driver layer (RX), I think it is too early to categorize >> Related/Unrelated SKB's, because we want to delay touching packet-data >> as long as possible (waiting for the prefetcher to get data into >> cache). > > You don't need to touch the headers in order to have a good idea > as to whether there is a strong possibility packets are related > or not. > > We have the hash available.
Dave, I assume you refer to the RSS hash result which is written by NIC HWs to the completion descriptor and then fed to the stack by the driver calling skb_set_hash(.)? Well, this can be taken even further. Suppose a the NIC can be programmed by the kernel to provide a unique flow tag on the completion descriptor per a given 5/12 tuple which represents a TCP (or other logical) stream a higher level in the stack is identifying to be in progress, and the driver plants that in skb->mark before calling into the stack. I guess this could yield nice speed up for the GRO stack -- matching based on single 32 bit value instead of per protocol (eth, vlan, ip, tcp) checks [1] - or hint which packets from the current window of "ready" completion descriptor could be grouped together for upper processing? Or. [1] some details to complete (...) here, on the last protocol hop we do need to verify that it would be correct to stick the incoming packet to the existing pending packet of this stream
