The existing implementation deals with the simple case where all packets
egressing through the qos enabled interface are of same type (for e.g.
Ethernet/ip4..) without dealing with the situations where egress traffic at QoS
enabled tx interface have different packet types. To deal with mixed traffic
situations (such as your case), little work is required in terms of improving
the classifier stage. The classifier can be implemented at worker thread either
before enqueue the packets into qos object associated with the output interface
or at some point earlier when output interface is known. The classifier will
first separate the packets based on their type and apply right offset/mask
value over the desired packets fields to compute the metadata (for e.g.
mbuf->sched value). At the later stage, when the packet is directed towards the
interface with QoS enabled, all the packets will be enqueued to the qos queues
based on the metadata computed earlier. May be you have better idea to deal
with this case :)
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of David Hotham via vpp-dev
Sent: Wednesday, October 12, 2016 11:33 AM
Subject: [vpp-dev] undefined behaviour in dpdk_hqos_metadata_set?
dpdk_hqos_metadata_set classifies traffic by selecting bits from each packet
according to the configured masks.
But what if the packet being inspected is shorter than expected?
For example, the default configuration includes this:
* Packet field to identify the pipe.
* Default value: Assuming Ethernet/IPv4/UDP packets, UDP payload bits 12 ..
.pktfield1_slabpos = 40,
.pktfield1_slabmask = 0x0000000FFF000000LLU,
What if an ARP request (or response) is sent out over the interface: won't
using that mask read from beyond the valid packet data?
Practically, I guess that this will mostly mean only that these occasional
packets get some arbitrary classification - which isn't so bad. But if we're
relying on undefined behaviour to not do worse than this, that would seem
This is a code-reading worry at the moment rather than an issue that I've
actually seen. Hopefully someone can assure me that there's some reason this
isn't a problem at all.
vpp-dev mailing list