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

Powered by blists - more mailing lists