On Tue, May 21, 2024 at 02:48:50PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > userspace, my proposal: > > > > > > > > if (!skb_is_gso(skb) || ((queue->flags & NFQA_CFG_F_GSO) && !skb_is_gso_sctp(skb))) > > > > return __nfqnl_enqueue_packet(net, queue, entry); > > > > > > This disables F_GSO with sctp packets, is sctp incompatible with nfqueue? > > > > This will send a big SCTP payload to userspace (larger than mtu), > > then, userspace will send the such big SCTP payload to kernelspace via > > nf_reinject(). > > I'm not following. > > if (!skb_is_gso(skb) || ((queue->flags & NFQA_CFG_F_GSO) && !skb_is_gso_sctp(skb))) > return __nfqnl_enqueue_packet(net, queue, entry); > > Means: > 1. skb isn't gso -> queue, OR > 2. Userspace can cope with large packets AND packet is not sctp-gso Yes, this is implicit case: skb is gso. This is adding an exception for sctp-gso. > -> queue > > -> sctp gso packets are fully software-segmented in kernel, and > we queue n packets instead of 1 superpacket. > > Apparently GSO SCTP is incompatible resp. skb_zerocopy() lacks > GSO_BY_FRAGS support. > > Too bad. Then, either extend skb_zerocopy() to deal with GSO_BY_FRAGS or poor man approach as above: enqueue n packets until that is supported. By reading this, my understanding is that you prefer to extend skb_zerocopy(), I pick up from Antonio's work and send a patch. > > Can kernel deal with SCTP packets larger than MTU? > > As far as I can see the gso helpers used in fwd and output > path handle this transparently, i.e., yes.
