[ovs-dev] [PATCH] netdev_dpdk.c: Add QoS functionality.

Ben Pfaff blp at nicira.com
Tue Oct 13 16:24:21 UTC 2015


On Wed, Sep 30, 2015 at 01:45:15PM +0100, Ian Stokes wrote:
> This patch provides the modifications required in netdev-dpdk.c and
> vswitch.xml to allow for a DPDK user space QoS algorithm.
> 
> This patch adds a QoS configuration structure for netdev-dpdk and
> expected QoS operations 'dpdk_qos_ops'. Various helper functions
> are also supplied.
> 
> Also included are the modifications required for vswitch.xml to allow a
> new QoS implementation for netdev-dpdk devices. This includes a new QoS type
> `us-policer` as well as its expected QoS table entries.
> 
> The QoS functionality implemented for DPDK devices is `us-policer`.
> This is an egress policer used to drop packets at configurable rate.
> 
> The INSTALL.DPDK.md guide has also been modified to provide an example
> configuration of `us-policer` QoS.
> 
> Signed-off-by: Ian Stokes <ian.stokes at intel.com>

Hi Ian.  I've reviewed the documentation changes and the conceptual
design, but not the code itself.

First, I'm not sure why it's a good idea to introduce a policer to begin
with.  Our experience is that ingress policing does not produce useful
results.  Perhaps it will be more effective for egress, but I have my
doubts about that; otherwise why would shaping generally be preferred
for egress?

With what kinds of traffic has this implementation been tested?  How
accurate is it?  TCP and UDP respond quite differently to policing.
Additionally, policing can be especially hard on traffic that involves
IP fragments, since dropping a single fragment causes the entire IP
datagram to be discarded after soaking up considerable CPU time on the
destination host for reassembly.

Since DPDK is all about performance, I'd expect some commentary on the
performance of this technique.  How much CPU overhead does it require on
the sender?

I don't like this trend toward putting essentially all of the DPDK
documentation in INSTALL.DPDK.md.  This commit adds far more of the
configuration details to that file than to vswitch.xml.  I'd prefer it
to be the opposite, only adding an example or two to INSTALL.DPDK.md and
the bulk of the information to vswitch.xml.

I would have guessed that Intel NICs have hardware queuing and QoS
features.  If so, they are undoubtedly more CPU-efficient than software
versions.  Are there plans to make use of those features in DPDK?

Thanks,

Ben.



More information about the dev mailing list