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

Ben Pfaff blp at ovn.org
Tue Apr 3 17:54:07 UTC 2018


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?

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.)


More information about the dev mailing list