netdev - Re: GRO: can't force packet up stack immediately?

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]

Date:   Fri, 4 Dec 2020 11:20:33 +0000
From:   Edward Cree <ecree.xilinx@...il.com>
To:     John Ousterhout <ouster@...stanford.edu>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: GRO: can't force packet up stack immediately?

On 03/12/2020 19:52, John Ousterhout wrote:
> Homa uses GRO to collect batches of packets for protocol processing,
> but there are times when it wants to push a batch of packet up through
> the stack immediately (it doesn't want any more packets to be
> processed at NAPI level before pushing the batch up). However, I can't
> see a way to achieve this goal.
It's kinda hacky, but you might be able to call netif_receive_skb_internal()
 yourself, and then return ERR_PTR(-EINPROGRESS), so that dev_gro_receive()
 returns GRO_CONSUMED.
Of course, you'd need to be careful about out-of-order issues in case
 any earlier homa packets were still sitting in the rx_list.

Other than that, I don't think there's currently a way for a protocol
 to tell GRO to flush out the whole rx_list (which could be argued to
 be a layering violation, anyway).  You might potentially be able to
 add a flag to struct napi_gro_cb and teach napi_gro_complete() or
 gro_normal_one() to check for it, but — we'd only consider adding
 something like that with an in-tree user, which your protocol doesn't
 appear to be AFAICT.

-ed