If only one specific output port becomes the bottleneck link in BMv2 due to high outgoing traffic, is it valid to measure that port’s packet loss by maintaining two counters:
(1) a counter in the ingress pipeline that counts how many packets selected that port via egress_spec, and
(2) a counter in the egress pipeline that counts how many packets were actually transmitted from that port?
By comparing these two counters, can we correctly determine how many packets were dropped for that specific port?
My understanding is that BMv2 uses a shared output buffer memory pool, but still keeps logical per-port output queues. When one port becomes congested, does BMv2 drop packets only for that congested port’s logical queue, or can drops also occur on other ports because they share the same memory pool? I would like to confirm how BMv2 actually behaves in this situation.
I need help,please.thanks
I am not certain, as it has been a while since I tried a test congesting an output port in BMv2, but there might be a behavior in BMv2’s implementation such that when a queue in the packet buffer fills up to its configured capacity (by default 64 packets, if I recall correctly, but easily changed by finding this constant, editing it, and recompiling the code from source), it backpressures any packets in ingress processing going to that queue, which if it continues leads to backpressuring software queues in BMv2 feeding the ingress pipeline, and if those fill up to some maximum threshold, new arriving packets are dropped.
This is not typically the way a real hardware switch would behave – they would typically have tail drop thresholds on the packet buffer queues, and/or other fancier queue or buffer management algorithms running in them (e.g. weighted RED).
Thank you. I did confirm which port was dropping packets by comparing the egress_spec counter with the actual egress counter. So this behavior is just a characteristic of the simulation software, right?
BMv2 is good for debugging P4 program behavior, in terms of what packets come in, and how they are modified, what tables they look up and the resulting actions, what counters are updated, what headers are modified, and perhaps a few other things like that.
In terms of real-time performance behavior as compared to a switch ASIC, BMv2 was never designed to mimic the performance of any real switch ASIC.
I give that response as part of the answer to your question “So this behavior is just a characteristic of the simulation software, right?”. BMv2 is a functional simulator for packet-in and packet-out, but not a performance simulator.
See this earlier answer to a different question for a possible lead on other software that might lead to something that is good for both P4 packet-in/packet-out behavior, and also may more realistically model the performance behavior of some real switch ASICs: Unexpected Queue Depth Spikes in BMv2 (v1model) During Congestion Control - #5 by kmftangchaoyang