Hi Jan, > -----Original Message----- > From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] > Sent: Friday, September 22, 2017 12:37 PM > To: O Mahony, Billy <billy.o.mah...@intel.com>; Kevin Traynor > <ktray...@redhat.com>; d...@openvswitch.org > Cc: Mechthild Buescher <mechthild.buesc...@ericsson.com>; Venkatesan > Pradeep <venkatesan.prad...@ericsson.com> > Subject: RE: [ovs-dev] [PATCH 0/4] prioritizing latency sensitive traffic > > Hi Billy, > > > -----Original Message----- > > From: O Mahony, Billy [mailto:billy.o.mah...@intel.com] > > Sent: Friday, 22 September, 2017 10:52 > > > > The next question is how to classify the ingress traffic on the NIC > > > and insert it into rx queues with different priority. Any scheme > > > implemented should preferably work with as many NICs as possible. > > > Use of the new rte_flow API in DPDK seems the right direction to go > here. > > > > [[BO'M]] This may be getting ahead of where we are but is it important to > know if a NIC does not support a prioritization scheme? > > Someone, Darrell I believe mentioned a capability discovery mechanism > > at one point. I was thinking it was not necessary as functionally > > nothing changes if prioritization is or is not supported. But maybe in terms > of an orchestrator it does make sense - as the it may want to want to make > other arrangements to protect control traffic in the absence of a working > prioritization mechanism. > > [Jan] In our use case the configuration of filters for prioritization would > happen "manually" at OVS deployment time with full knowledge of the NIC > type and capabilities. A run-time capability discovery mechanism is not really > needed for that. But it would anyway be good to get a feedback if the > configured filter is supported by the present NIC or if the prioritization > will > not work. > [[BO'M]] There is a log warning message but if something more software-friendly is required maybe the ovsdb entry for the other_config could be cleared by vswitchd if the interface can't perform? > > > > > > We are very interested in starting the dialogue how to configure the > > > {queue, priority, filter} mapping in OVS and which filters are most > > > meaningful to start with and supported by most NICs. Candidates > > > could include VLAN tags and p- bits, Ethertype and IP DSCP. > > Any feedback as to the viability of filtering on those fields with i40e and > ixgbe? [[BO'M]] There is a flex filter feature which should make this possible for XL710. I will verify. > > > > > > > One thing that we consider important and that we would not want to > > > lose with prioritization is the possibility to share load over a > > > number of PMDs with RSS. So preferably the prioritization and RSS > > > spread over a number of rx queues were orthogonal. > > > > [[BO'M]] We have a proposed solution for this now. Which is simply to > > change the RETA table to avoid RSS'd packets 'polluting' the priority > > queue. It hasn't been implemented but it should work. That's in the > context of DPDK/FlowDirector/XL710 but rte_flow api should allow this too. > > [Jan] Does this mean there is work needed to enhance the NIC firmware, the > i40e DPDK PMD, or the rte_flow API (or any combination of those)? What > about the ixgbe PMD in this context? Will the Niantic support similar > classification? [[BO'M]] I'd imagine that all NICs implementing RSS have a RETA and I'm sure it's accessible by both fdir and rte_flow currently. In terms of Niantic supporting queue assignment based on VLAN tags etc I'm not so sure. I'll take an AR to dig into this. > > Do you have a pointer to Fortville documentation that would help us to > understand how i40e implements the rte_flow API.
[[BO'M]] AFAIK the flow API is pretty expressive. The issue would be more with NIC support. There is the XL710 datasheet https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xl710-10-40-controller-datasheet.pdf which tbh I find hard to figure out how the various filter mechanism interact. > > Thanks, Jan _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
