On Wed, 17 Jun 2026 at 22:49, Ilya Maximets <[email protected]> wrote: > > On 2/27/26 9:29 AM, David Marchand via dev wrote: > > Prepare dpif-netdev to handle larger batches. > > > > Metering does not need support for large batches, as it is invoked > > before actions that will produce large batches in next commits (ip > > reassembly, > > GSO). > > It is possible for metering to go after ct(commit). I think, you may even > just add a meter action to your ipf test in the patch 7 to reproduce. > > There is a way to refactor the meter action to avoid having the stack > allocated arrays that depend on the batch size. It will look somewhat > like this: > > 1. Go over all the bands and sub the full batch value. Remember failed > bands in a bitmap. MAX_BANDS is 8, so the bitmap is simple. > > 2. Return if the bitmap is empty. > > 3. For each packet: > For each failed band in a bitmap (ctz): > Try to sub, remember the highest failed band. > Count band bytes and packets for the highest band. > > 4. Add counted band stats to the actual band. > > Since we're iterating over the packets in the outer loop in this case, > there should be no need to store the highest bands per packet across > iteration, so simple temporary variables can be used. > > Inner loop for the failed bands should be fast enough. > > Alternatively, we could also split the large batch as you did in other > places before calling the actual meter code.
I think I got those changes right, so let's go with your proposal. > > Also update dpif-netdev output action, as it relies on structures sized > > against > > NETDEV_MAX_BURST (for stats/cycles tracking, and txq distribution). > > Maybe this one split can be avoided? We could try to track the growth > of the output_pkts batch and make the output_pkts_rxqs dynamic and > grow it at the same time. The only place where the output_pkts can > grow seem to be dp_execute_output_chunk(). We could store the previous > size, then add_array(), check if the size changed and realloc the rxqs > array before updating the pointer in it. This should allow us to avoid > extra splitting work. WDYT? This looks doable, later in the series. For readability, I will split this in multiple patches. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
