[ovs-dev] [RFC v2 1/2] ingress scheduling: schema and docs

O Mahony, Billy billy.o.mahony at intel.com
Wed Apr 4 08:17:26 UTC 2018



> -----Original Message-----
> From: Ben Pfaff [mailto:blp at ovn.org]
> Sent: Tuesday, April 3, 2018 6:54 PM
> To: O Mahony, Billy <billy.o.mahony at intel.com>
> Cc: dev at openvswitch.org; i.maximets at samsung.com
> Subject: Re: [ovs-dev] [RFC v2 1/2] ingress scheduling: schema and docs
> 
> On Tue, Apr 03, 2018 at 09:06:18AM +0000, O Mahony, Billy wrote:
> > Hi Ben,
> >
> > > -----Original Message-----
> > > From: Ben Pfaff [mailto:blp at ovn.org]
> > > Sent: Sunday, April 1, 2018 1:27 AM
> > > To: O Mahony, Billy <billy.o.mahony at intel.com>
> > > Cc: dev at openvswitch.org; i.maximets at samsung.com
> > > Subject: Re: [ovs-dev] [RFC v2 1/2] ingress scheduling: schema and
> > > docs
> > >
> > > On Wed, Mar 28, 2018 at 11:11:57PM +0100, Billy O'Mahony wrote:
> > > > Signed-off-by: Billy O'Mahony <billy.o.mahony at intel.com>
> > > > ---
> > > >  Documentation/howto/dpdk.rst | 18 ++++++++++++++++++
> > > >  vswitchd/vswitch.ovsschema   |  9 +++++++--
> > > >  vswitchd/vswitch.xml         | 40
> > > ++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 65 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/Documentation/howto/dpdk.rst
> > > > b/Documentation/howto/dpdk.rst index 79b626c..fca353a 100644
> > > > --- a/Documentation/howto/dpdk.rst
> > > > +++ b/Documentation/howto/dpdk.rst
> > > > @@ -237,6 +237,24 @@ respective parameter. To disable the flow
> > > > control at
> > > tx side, run::
> > > >
> > > >      $ ovs-vsctl set Interface dpdk-p0 options:tx-flow-ctrl=false
> > > >
> > > > +Ingress Scheduling
> > > > +------------------
> > > > +
> > > > +The ingress scheduling feature is described in general in
> > > > +``ovs-vswitchd.conf.db (5)``.
> > > > +
> > > > +Ingress scheduling currently only supports setting a priority for
> > > > +incoming packets for an entire interface. Priority levels 0
> > > > +(lowest) to 3 (highest) are supported.  The default priority is 0.
> > > > +
> > > > +Interfaces of type ``dpdk`` and ``dpdkvhostuserclient`` support
> > > > +ingress scheduling.
> > > > +
> > > > +To prioritize packets on a particular port:
> > > > +
> > > > +    $ ovs-vsctl set Interface dpdk0 \
> > > > +        ingress_sched=port_prio=3
> > >
> > > I'm happy to see experimentation in this area.  But, since it is
> > > specified to particular kinds of interfaces, and because it is
> > > likely to evolve in the future, I think I would prefer to see it
> > > defined in term of the interface-type-specific "options" field.  Does that
> make sense?
> > >
> >
> > I did have as interface-type-specific configuration originally mainly as it kept
> changes within areas I was familiar with. But it was pointed out by Ilya that
> there was nothing dpdk specific to this feature and that by making the
> configuration more general that we could "provide ingres scheduling for all the
> port types at once". In particular it would be useful for those implementing to
> implement netdev-netmap.
> >
> > So that was the motivation behind the generalized configuration at least.
> 
> I think that generalized configuration can make sense, but I wonder what the
> overall universe of ingress scheduler configuration looks like.  Are there multi-
> vendor examples of how different software or hardware do ingress QoS?
A few vendors have started supporting DPDK rte_flow API albeit just for classification offload. But I it could be a future standard offload API. But for this RFC which is just per-port granularity the configuration only affects the datapath.
> 
> I find myself wondering if we should just add an "ingress_qos" column that
> points to a QoS row.  Probably, there would initially only be one ingress QoS
> type, and it might not have any queues to define, but this would at least be quite
> extensible and fairly familiar to users.  (It could also obsolete the
> ingress_policing_rate and ingress_policing_burst
> columns.)
I think that would be a good solution too. Another reason for moving the config from Interface options was that the configurations were potentially quite large and a separate column would be cleaner. So a separate table would also work well. Although for just prioritizing on a per-port basis the options field would be perfectly fine.


More information about the dev mailing list