On Wed, Apr 04, 2018 at 08:17:26AM +0000, O Mahony, Billy wrote: > > > > -----Original Message----- > > From: Ben Pfaff [mailto:[email protected]] > > Sent: Tuesday, April 3, 2018 6:54 PM > > To: O Mahony, Billy <[email protected]> > > Cc: [email protected]; [email protected] > > 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:[email protected]] > > > > Sent: Sunday, April 1, 2018 1:27 AM > > > > To: O Mahony, Billy <[email protected]> > > > > Cc: [email protected]; [email protected] > > > > 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 <[email protected]> > > > > > --- > > > > > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
