Hi David,

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
To: vpp-dev@lists.fd.io
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

Reply via email to