dpif-linux: Give each port its own userspace-kernel channel.

Userspace-kernel communication is a possible bottleneck when OVS is
receiving a large number of flow set up requests.  To help prevent a bad
actor from consuming too much of this resource, we introduced channels
to segegrate traffic.  Previously, we created 17 channels and
round-robin assigned ports to one of 16 channels (the 17th was reserved
for use by the system).  This meant if there were more than 16 ports,
sharing of channels would occur.

This commit creates a new channel for each port, so that there is no
more sharing and better isolation.  The special system port uses the
"ovs-system"'s channel (port 0), since it is not heavily loaded.

This also fixes an issue introduced in commit acf60855 (ofproto-dpif:
Use a single underlying datapath across multiple bridges.) where ports
that were added at run-time were given the special system channel.

Issue #12073

Signed-off-by: Justin Pettit <jpettit@nicira.com>

1 files changed, 4 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index ab7ef4da..3f06a7a8 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,10 @@ post-v1.9.0
     - The maximum size of the MAC learning table is now configurable.
     - New support for the VXLAN tunnel protocol (see the IETF draft here:
       http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02).
+    - With the Linux datapath, packets for new flows are now queued
+      separately on a per-port basis, so it should no longer be
+      possible for a large number of new flows arriving on one port to
+      prevent new flows from being processed on other ports.
     - New "vlog/disable-rate-limit" and "vlog/enable-rate-limit" commands
       available through ovs-appctl allow control over logging rate limits.
     - The OpenFlow "dp_desc" may now be configured by setting the value of