Hi Billy,
> -----Original Message-----
> From: O Mahony, Billy [mailto:[email protected]]
> 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.
> >
> > 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?
> >
> > 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?
Do you have a pointer to Fortville documentation that would help us to
understand how i40e implements the rte_flow API.
Thanks, Jan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
