On Wed, 26 Nov 2025 at 18:25, Mike Pattrick via dev
<[email protected]> wrote:
> > > + ip6 = (const struct ovs_16aligned_ip6_hdr *) l3;
> > > +
> > > + if (mtu < 1280) {
> > > + return NULL;
> > > + }
> >
> > I don't have all the context in mind.
> > What does 1280 stand for?
[snip]
> > And here, why 576?
> >
>
> The 1280 above and 576 here are RFC specified minimum mtu's, both of these
> checks mirror how pmtu is implemented in the linux kernel.
There is a clear 1280 minimum value defined in RFC8200, and Linux
exposes IPV6_MIN_MTU (linux/ipv6.h).
But nothing for IPv4 from Linux, and I am not sure which RFC defines a minimum.
So at least using some OVS defines would make it more readable.
[snip]
> > > @@ -9049,7 +9178,45 @@ push_tnl_action(const struct dp_netdev_pmd_thread
> > *pmd,
> > > err = -EINVAL;
> > > goto error;
> > > }
> > > - err = netdev_push_header(tun_port->port->netdev, batch, data);
> > > +
> > > + netdev = tun_port->port->netdev;
> > > + if (netdev->mtu_user_config &&
> > > + netdev_get_mtu(netdev, &mtu) == 0) {
> > > + struct dp_packet_batch icmp_batch;
> > > +
> > > + dp_packet_batch_init(&icmp_batch);
> > > + DP_PACKET_BATCH_REFILL_FOR_EACH (i, size, packet, batch) {
> > > + int len = dp_packet_get_send_len(packet) + data->header_len;
> >
> > I suspect this will not work with TSO packets:
> > dp_packet_get_send_len() returns a length before segmentation and it
> > will not be the actual length of sent data.
> >
>
> I believe you are correct, also I think this is the second misuse of
> dp_packet_get_send_len() - out of three current uses - in a few months.
> Maybe that function should be renamed for clarity?
Either rename, or rethink the cutlen stuff.
>
> As a side note, I was looking at the kernel module and unless I'm reading
> it wrong, queue_gso_packets() appears to segment the packet before applying
> cutlen whereas other areas appear to apply cutlen before segmentation. I
> don't know if that's intentional.
This seems wrong.
More generally, whether in the kernel or userspace datapath, cutlen is
evaluated against a current packet size for implementing packet
truncation.
For TSO packets it will not be the actual size after segmentation.
I had opened an issue on similar topic for userspace datapath:
https://issues.redhat.com/browse/FDP-1645
--
David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
