Hi All,
As a suggestion for dealing with indicating success or otherwise of ingress
scheduling configuration and also advertising an Interfaces ingress scheduling
capability I'm suggesting both these can be written back to the Interface
tables other_config column.
The schema change (change with respect to the current patch-set) would be like
this.
</p>
<column name="other_config" key="ingress_sched">
<p>
The format of the ingress_sched field is specified in ovs-fields(7) in
the ``Matching'' and ``FIELD REFERENCE'' sections.
</p>
</column>
+ <column name="other_config" key="ingress_sched_cap">
+ <p>
+ A comma separated list of ovs-fields(7) that the interface supports for
+ ingress scheduling. If ingress scheduling is not supported this column
+ is cleared.
+ </p>
+ </column>
+ <column name="other_config" key="ingress_sched_ok">
+ <p>
+ If the specified ingress scheduling could not be applied, Open vSwitch
+ sets this column to an error description in human readable form.
+ Otherwise, Open vSwitch clears this column.
+ </p>
+ </column>
</group>
It would be nice to have input on the feasibility of writing back to the
Interface table - there is already a few columns that are written to in
Interface table - e.g stats column and ofport column. But this would make the
other_config column both read and write which hopefully doesn't confuse the
mechanism that notifies Interface table changes from ovsdb into vswitchd.
Regards,
Billy.
> -----Original Message-----
> From: Jan Scheurich [mailto:[email protected]]
> Sent: Friday, September 22, 2017 12:37 PM
> To: O Mahony, Billy <[email protected]>; Kevin Traynor
> <[email protected]>; [email protected]
> Cc: Mechthild Buescher <[email protected]>; Venkatesan
> Pradeep <[email protected]>
> Subject: RE: [ovs-dev] [PATCH 0/4] prioritizing latency sensitive traffic
>
> 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
