On Thu, Sep 19, 2019 at 9:07 AM Marcelo Ricardo Leitner
[off-list ref] wrote:

On Thu, Sep 19, 2019 at 08:55:22AM -0400, Willem de Bruijn wrote:

quoted

On Wed, Sep 18, 2019 at 12:58 PM Marcelo Ricardo Leitner
[off-list ref] wrote:

quoted

On Wed, Sep 18, 2019 at 12:17:08PM -0400, Willem de Bruijn wrote:

quoted

On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert
[off-list ref] wrote:

quoted

This patchset adds support to do GRO/GSO by chaining packets
of the same flow at the SKB frag_list pointer. This avoids
the overhead to merge payloads into one big packet, and
on the other end, if GSO is needed it avoids the overhead
of splitting the big packet back to the native form.

Patch 1 Enables UDP GRO by default.

Patch 2 adds a netdev feature flag to enable listifyed GRO,
this implements one of the configuration options discussed
at netconf 2019.

Patch 3 adds a netdev software feature set that defaults to off
and assigns the new listifyed GRO feature flag to it.

Patch 4 adds the core infrastructure to do fraglist GRO/GSO.

Patch 5 enables UDP to use fraglist GRO/GSO if configured and no
GRO supported socket is found.

Very nice feature, Steffen. Aside from questions around performance,
my only question is really how this relates to GSO_BY_FRAGS.

They do the exact same thing AFAICT: they GSO according to a
pre-formatted list of fragments/packets, and not to a specific size
(such as MSS).

quoted

More specifically, whether we can remove that in favor of using your
new skb_segment_list. That would actually be a big first step in
simplifying skb_segment back to something manageable.

The main issue (that I know) on obsoleting GSO_BY_FRAGS is that
dealing with frags instead of frag_list was considered easier to be
offloaded, if ever attempted.  So this would be a step back on that
aspect.  Other than this, it should be doable.

But GSO_BY_FRAGS also uses frag_list, not frags?

/me is scratching his head.
My bad. I thought it was already using frags. Thanks.

quoted

And list_skb->len for mss.

Which stands more for 'current frag size', yes.
(list_skb, not head_skb)

Great. I thought I missed something :)

Frags might be cheaper from an allocation point. If at some point
going down that road.

But in the meantime, it looks like we can handle these too with
skb_segment_list, then (not necessarily in the initial patch set).