[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <871shxy4zv.fsf@linkitivity.dja.id.au>
Date: Wed, 07 Feb 2018 12:15:32 +1100
From: Daniel Axtens <dja@...ens.net>
To: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>
Subject: qdisc_pkt_len_init: SCTP/GSO_BY_FRAGS and robustness questions
Hi Marcelo and Eric,
I'm working on checking code that might be impacted by GSO_BY_FRAGS -
after finding that the token bucket filter qdisc code doesn't handle it
properly, DaveM said I should look for other places where this might be
an issue [0].
I'm currently looking at qdisc_pkt_len_init in net/core/dev.c. This is
called by __dev_queue_xmit, before validate_xmit_skb, so before an SCTP
skb would be segmented if the hardware doesn't support SCTP offload.
There are two things I was hoping you two could offer some advice on:
1) Eric, in 7c68d1a6b4db ("net: qdisc_pkt_len_init() should be more
robust") you replaced a chunk of code that is similar to the code
found in skb_gso_transport_seglen() and replaced it with more robust
code. Do we need to change skb_gso_transport_seglen() in a similar way?
2) Marcelo, unlike skb_gso_transport_seglen(), where you added a case
for SCTP in 90017accff61 ("sctp: Add GSO support"), there doesn't
seem to be a GSO_BY_FRAGS or SCTP check in qdisc_pkt_len_init, so I
think the accounting is probably wrong for SCTP. I'm not 100% sure
how to fix this as it's now quite different from the calcuations in
skb_gso_transport_seglen() - so I was hoping that you might have an
idea.
Thanks in advance!
[0]: https://patchwork.ozlabs.org/patch/869145/#1852414
Regards,
Daniel
Powered by blists - more mailing lists