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

Ben Pfaff blp at ovn.org
Wed Apr 4 17:00:06 UTC 2018


On Wed, Apr 04, 2018 at 08:17:26AM +0000, O Mahony, Billy wrote:
> 
> 
> > -----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.

I'd favor using a QoS row then, if you're willing to implement it.


More information about the dev mailing list