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] [day] [month] [year] [list]

Message-ID: <CAGXJAmyhULC3g+UGobd_Vo3zUvaxLMLJFXZBD9OY8w4nJhNo1g@mail.gmail.com>
Date:   Sun, 6 Dec 2020 21:51:16 -0800
From:   John Ousterhout <ouster@...stanford.edu>
To:     Edward Cree <ecree.xilinx@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: GRO: can't force packet up stack immediately?

On Fri, Dec 4, 2020 at 3:20 AM Edward Cree <ecree.xilinx@...il.com> wrote:
>
> 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.

It doesn't appear to me that this approach will work, because the
packet I want to force up through the stack is not the new one being
passed into homa_gro_receive, but one of the packets on the list
passed in as the first argument (gro_head in dev_gro_receive).
Removing a packet from this list looks tricky, because it also
requires updating a count in the napi structure, which
homa_gro_receive doesn't have immediate access to. I might be able to
figure out a way to get the napi pointer, but this is starting to feel
pretty hacky (and brittle w.r.t. kernel changes).

BTW, out-of-order issues don't matter for Homa; this is one of the
areas where the "protocol independent" parts of the networking code
build in TCP-specific assumptions, which are either unnecessary or, in
some cases, problematic for Homa.

Thanks anyway for the suggestion.

-John-