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