lkml.org 
[lkml]   [2024]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] net: add TCP fraglist GRO support
    Felix Fietkau wrote:
    > On 23.04.24 16:34, Paolo Abeni wrote:
    > > On Tue, 2024-04-23 at 14:23 +0200, Felix Fietkau wrote:
    > >> On 23.04.24 14:11, Eric Dumazet wrote:
    > >> > On Tue, Apr 23, 2024 at 1:55 PM Felix Fietkau <nbd@nbd.name> wrote:
    > >> > >
    > >> > > In the world of consumer-grade WiFi devices, there are a lot of chipsets
    > >> > > with limited or nonexistent SG support, and very limited checksum
    > >> > > offload capabilities on Ethernet. The WiFi side of these devices is
    > >> > > often even worse. I think fraglist GRO is a decent fallback for the
    > >> > > inevitable corner cases.
    > >> >
    > >> > What about netfilter and NAT ? Are they okay with NETIF_F_FRAGLIST_GRO already ?
    > >> >
    > >> > Many of these devices are probably using NAT.
    > >>
    > >> In my tests, nftables NAT works just fine, both with and without
    > >> flowtable offloading. I didn't see anything in netfilter that would have
    > >> a problem with this.
    > >
    > > I see you handle explicitly NAT changes in __tcpv4_gso_segment_csum(),
    > > like the current UDP code.
    > >
    > > The TCP header has many other fields that could be updated affecting
    > > the TCP csum.
    > > Handling every possible mutation looks cumbersome and will likely
    > > reduce the performance benefits.
    > >
    > > What is your plan WRT other TCP header fields update?
    >
    > I think that should be easy enough to handle. My patch already only
    > combines packets where tcp_flag_word(th) is identical. So when
    > segmenting, I could handle all flags changes with a single
    > inet_proto_csum_replace4 call.
    >
    > > Strictly WRT the patch, I guess it deserves to be split in series,
    > > moving UDP helpers in common code and possibly factoring out more
    > > helpers with separate patches.
    > Will do.

    A significant chunk of the complexity is in the
    tcp[46]_check_fraglist_gro sk match. Is this heuristic worth the
    complexity?

    It seems that the platforms that will enable NETIF_F_FRAGLIST will
    be mainly forwarding planes.

    If keeping, this refinement can probably a separate follow-on patch in
    the series too:

    - refactor existing udp code
    - add segmentation support to handle such packets on tx
    - add coalescing support that starts building such packets on rx
    - refine coalescing choice

    > > e.g. in __tcpv4_gso_segment_csum() is quite similar
    > > __udpv4_gso_segment_csum() - even too much, as the tcp csum should be
    > > always be updated when the ports or addresses change ;)
    >
    > Will fix that.
    >
    > Thanks,
    >
    > - Felix



    \
     
     \ /
      Last update: 2024-04-24 03:25    [W:2.867 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site