On Tue, 9 Dec 2025 at 10:59, David Marchand <[email protected]> wrote:
> > > +static void
> > > +dp_packet_gso_update_segment(struct dp_packet *seg, int seg_no, int 
> > > n_segs,
> > > +                             uint16_t tso_segsz)
> > >  {
> > > -    static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
> > > -    struct dp_packet_batch *curr_batch = *batches;
> >
> > > +    bool udp_tnl = dp_packet_tunnel_vxlan(seg)
> > > +                   || dp_packet_tunnel_geneve(seg);
> > > +    bool gre_tnl = dp_packet_tunnel_gre(seg);
> >
> > Only disadvantage I can see from change is that these have to be read
> > for every update. I guess it shouldn't make any real difference and
> > adding them to the API doesn't seem very nice either
>
> I agree, reading the current segment properties is unneeded, because
> the properties of the original packet are known from the start.
>
> This is an internal API, I don't mind updating it: we are already
> passing segment numbers which are not that elegant to me :-).
> Maybe a cleaner API would be to pass the original packet, and let the
> compiler notice we always refer to the same info (idem with nr_segs
> and tso_segsz) for all segments?

This triggers a divide by 0 as the original packet get tso reset.
I could defer this after call to dp_packet_gso_update_segment(), but
still, this is awkward with next patch.

I'll simply pass all needed info as input parameters.


-- 
David Marchand

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to