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.sto...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
