Paolo Abeni wrote:
> On Tue, 2024-03-26 at 18:25 +0100, Richard Gobert wrote:
>> Paolo Abeni wrote:
>>> Hi,
>>>
>>> On Tue, 2024-03-26 at 16:02 +0100, Richard Gobert wrote:
This patch is meaningful by itself - removing checks against non-relevant
packets and making the flush/flush_id chec
On Tue, 2024-03-26 at 18:25 +0100, Richard Gobert wrote:
> Paolo Abeni wrote:
> > Hi,
> >
> > On Tue, 2024-03-26 at 16:02 +0100, Richard Gobert wrote:
> > > This patch is meaningful by itself - removing checks against non-relevant
> > > packets and making the flush/flush_id checks in a single plac
Paolo Abeni wrote:
> Hi,
>
> On Tue, 2024-03-26 at 16:02 +0100, Richard Gobert wrote:
>> This patch is meaningful by itself - removing checks against non-relevant
>> packets and making the flush/flush_id checks in a single place.
>
> I'm personally not sure this patch is a win. The code churn is
Hi,
On Tue, 2024-03-26 at 16:02 +0100, Richard Gobert wrote:
> This patch is meaningful by itself - removing checks against non-relevant
> packets and making the flush/flush_id checks in a single place.
I'm personally not sure this patch is a win. The code churn is
significant. I understand this
Willem de Bruijn wrote:> One issue: if the do this move in net/next, then a
later fix that
> relies on it cannot be backporter to older stable kernels.
>
I understand. I can either add a first commit to this series which fixes
the bug by checking ->flush and ->flush_id in udp_gro_receive_segment
Richard Gobert wrote:
> Eric Dumazet wrote:
> >
> > I do not understand this patch 4/4 then.
> >
> > Why bother moving stuff in net/ipv4/tcp_offload.c if we plan to move
> > it back to where it belongs ?
>
> Willem also pointed that out, and I agree. I'll post a v5 and move this
> functionality
Eric Dumazet wrote:
>
> I do not understand this patch 4/4 then.
>
> Why bother moving stuff in net/ipv4/tcp_offload.c if we plan to move
> it back to where it belongs ?
Willem also pointed that out, and I agree. I'll post a v5 and move this
functionality to gro.c. Currently, gro_network_flush w
On Tue, Mar 26, 2024 at 3:43 PM Richard Gobert wrote:
>
> Eric Dumazet wrote:
> > On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert
> > wrote:
> >>
> >> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> >> iph->id, ...) against all packets in a loop. These flush checks are used
Eric Dumazet wrote:
> On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert
> wrote:
>>
>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
>> iph->id, ...) against all packets in a loop. These flush checks are used
>> currently only in tcp flows in GRO.
>
> I think this is a bug.
>
On Mon, Mar 25, 2024 at 7:27 PM Richard Gobert wrote:
>
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used
> currently only in tcp flows in GRO.
I think this is a bug.
GRO should not aggregate packets i
Willem de Bruijn wrote:
> My main concern is moving this code to tcp_offload.c, if it likely
> soon will be moved elsewhere again.
Got it. I'll move these functions to gro.c and post a v5 with Jakub's
requests as well.
Richard Gobert wrote:
> Willem de Bruijn wrote:
> > In v3 we discussed how the flush on network layer differences (like
> > TTL or ToS) currently only affect the TCP GRO path, but should apply
> > more broadly.
> >
> > We agreed that it is fine to leave that to a separate patch series.
> >
> > Bu
Willem de Bruijn wrote:
> In v3 we discussed how the flush on network layer differences (like
> TTL or ToS) currently only affect the TCP GRO path, but should apply
> more broadly.
>
> We agreed that it is fine to leave that to a separate patch series.
>
> But seeing this patch, it introduces a l
On Mon, 25 Mar 2024 19:25:43 +0100 Richard Gobert wrote:
> + const u32 id = ntohl(*(__be32 *)&iph->id);
> + const u32 id2 = ntohl(*(__be32 *)&iph2->id);
> + const int flush_id = ntohs(id >> 16) - ntohs(id2 >> 16);
The endian conversions don't match types here. sparse is unhappy.
If id
Richard Gobert wrote:
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used
> currently only in tcp flows in GRO.
>
> These checks need to be done only once in tcp_gro_receive and only against
> the found p
15 matches
Mail list logo
