[ovs-dev] [PATCH 0/4] prioritizing latency sensitive traffic

O Mahony, Billy billy.o.mahony at intel.com
Tue Oct 17 16:14:31 UTC 2017


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:jan.scheurich at ericsson.com]
> Sent: Friday, September 22, 2017 12:37 PM
> To: O Mahony, Billy <billy.o.mahony at intel.com>; Kevin Traynor
> <ktraynor at redhat.com>; dev at openvswitch.org
> Cc: Mechthild Buescher <mechthild.buescher at ericsson.com>; Venkatesan
> Pradeep <venkatesan.pradeep at ericsson.com>
> Subject: RE: [ovs-dev] [PATCH 0/4] prioritizing latency sensitive traffic
> 
> Hi Billy,
> 
> > -----Original Message-----
> > From: O Mahony, Billy [mailto:billy.o.mahony at 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.
> 
> > >
> > > 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



More information about the dev mailing list