> -----Original Message-----
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Wednesday, April 4, 2018 6:00 PM
> To: O Mahony, Billy <billy.o.mah...@intel.com>
> Cc: d...@openvswitch.org; i.maxim...@samsung.com
> Subject: Re: [ovs-dev] [RFC v2 1/2] ingress scheduling: schema and docs
>
> On Wed, Apr 04, 2018 at 08:17:26AM +0000, O Mahony, Billy wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > Sent: Tuesday, April 3, 2018 6:54 PM
> > > To: O Mahony, Billy <billy.o.mah...@intel.com>
> > > Cc: d...@openvswitch.org; i.maxim...@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:b...@ovn.org]
> > > > > Sent: Sunday, April 1, 2018 1:27 AM
> > > > > To: O Mahony, Billy <billy.o.mah...@intel.com>
> > > > > Cc: d...@openvswitch.org; i.maxim...@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.mah...@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.
If later versions of ingress scheduling have complex configurations then I'd
agree to putting them in QoS table. But if, as for the current effort, config
is just a simple priority then a new item in the config column of the Interface
table is simplest. At least until I get a chance to get the effects fully
characterized in a few different scenarios. At that point I'd happily revisit
more sophisticated configurations.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
