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 :)
Thanks, Jasvinder 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 .. 23 */ .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 risky... 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. Thanks David
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
