GRO: can't force packet up stack immediately?

GRO: can't force packet up stack immediately?

[John Ousterhout]

I recently upgraded my kernel module implementing the Homa transport
protocol from 4.15.18 to 5.4.80, and a GRO feature available in the
older version seems to have gone away in the newer version. In
particular, it used to be possible for a protocol's xxx_gro_receive
function to force a packet up the stack immediately by returning that
skb as the result of xxx_gro_receive. However, in the newer kernel
version, these packets simply get queued on napi->rx_list; the queue
doesn't get flushed up-stack until napi_complete_done is called or
gro_normal_batch packets accumulate. For Homa, this extra level of
queuing gets in the way.

Is there any way for a xxx_gro_receive function to force a packet (in
particular, one of those in the list passed as first argument to
xxx_gro_receive) up the protocol stack immediately? I suppose I could
set gro_normal_batch to 1, but that might interfere with other
protocols that really want the batching.

-John-

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

[Eric Dumazet]

On 12/3/20 8:03 PM, John Ousterhout wrote:
> I recently upgraded my kernel module implementing the Homa transport
> protocol from 4.15.18 to 5.4.80, and a GRO feature available in the
> older version seems to have gone away in the newer version. In
> particular, it used to be possible for a protocol's xxx_gro_receive
> function to force a packet up the stack immediately by returning that
> skb as the result of xxx_gro_receive. However, in the newer kernel
> version, these packets simply get queued on napi->rx_list; the queue
> doesn't get flushed up-stack until napi_complete_done is called or
> gro_normal_batch packets accumulate. For Homa, this extra level of
> queuing gets in the way.


Could you describe what the issue is ?

> 
> Is there any way for a xxx_gro_receive function to force a packet (in
> particular, one of those in the list passed as first argument to
> xxx_gro_receive) up the protocol stack immediately? I suppose I could
> set gro_normal_batch to 1, but that might interfere with other
> protocols that really want the batching.
> 
> -John-
> 

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

[John Ousterhout]

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. I can return a packet pointer as the
result of homa_gro_receive (and this used to be sufficient to push the
packet up the stack). What happens now is:
* dev_gro_receive calls napi_gro_complete (same as before)
* napi_gro_complete calls gro_normal_one, whereas it used to call
netif_receive_skb_internal
* gro_normal_one just adds the packet to napi->rx_list.

Then NAPI-level packet processing continues, until eventually
napi_complete_done is called; it invokes gro_normal_list, which calls
netif_receive_skb_list_internal.

Because of this, packets can be delayed several microseconds before
they are pushed up the stack. Homa is trying to squeeze out latency,
so the extra delay is undesirable.

-John-

On Thu, Dec 3, 2020 at 11:35 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 12/3/20 8:03 PM, John Ousterhout wrote:
> > I recently upgraded my kernel module implementing the Homa transport
> > protocol from 4.15.18 to 5.4.80, and a GRO feature available in the
> > older version seems to have gone away in the newer version. In
> > particular, it used to be possible for a protocol's xxx_gro_receive
> > function to force a packet up the stack immediately by returning that
> > skb as the result of xxx_gro_receive. However, in the newer kernel
> > version, these packets simply get queued on napi->rx_list; the queue
> > doesn't get flushed up-stack until napi_complete_done is called or
> > gro_normal_batch packets accumulate. For Homa, this extra level of
> > queuing gets in the way.
>
>
> Could you describe what the issue is ?
>
> >
> > Is there any way for a xxx_gro_receive function to force a packet (in
> > particular, one of those in the list passed as first argument to
> > xxx_gro_receive) up the protocol stack immediately? I suppose I could
> > set gro_normal_batch to 1, but that might interfere with other
> > protocols that really want the batching.
> >
> > -John-
> >

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

[Edward Cree]

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

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

[John Ousterhout]

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