On 2/27/26 9:29 AM, David Marchand via dev wrote: > dp-packet batches can hold only a fixed count of packets since their > introduction. > > This limitation makes it impossible to split packets/emit more than > the batch size during the processing of one batch. > > This series proposes to dynamically grow those batches when a > NETDEV_MAX_BURST threshold is reached. > > Sending as RFC as I did not explore many options and I would like to hear > others opinions.
Thanks, David! And sorry for the long delay. I think, this is a good change to have in general. > Also, the current approach ends up with kind of duplicated logic in dpif > and netdev layers. > Ideally, the limitations on the maximum size of a batch to be > transmitted would be netdev specific but dpif-netdev code has some ties > with the fixed size ([NETDEV_MAX_BURST] arrays). As I noted in the patch 8, the only path that actually requires batches of NETDEV_MAX_BURST packets is all the lookups on Rx side. We can't get a batch larger than that from netdevs, so the only place where we need to slice batches into NETDEV_MAX_BURST-sized chunks appears to be the recirculation. Which should be fine, I suppose. The meter can be re-worked to avoid the slicing, the output_pkts and the rxqs statistics update can also avoid the static arrays with some slight re-work. So, it should be possible to avoid most of the duplication, if we want to. Alternative might be to create another macro iterator for batch chunks, which will probably not be pretty on the inside, but will hide the duplicated slicing work. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
