[ovs-git] [openvswitch/ovs] 74cd69: netdev-dpdk: Support the link speed of XL710

GitHub noreply at github.com
Mon Aug 27 20:30:10 UTC 2018


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 74cd69a479cc0e6056538e9f412a89b13752d237
      https://github.com/openvswitch/ovs/commit/74cd69a479cc0e6056538e9f412a89b13752d237
  Author: Xu Binbin <xu.binbin1 at zte.com.cn>
  Date:   2018-08-27 (Mon, 27 Aug 2018)

  Changed paths:
    M lib/netdev-dpdk.c

  Log Message:
  -----------
  netdev-dpdk: Support the link speed of XL710

In the scenario of XL710, the link speed which stored in the table
of Interface is not 40G. Because the implementation of query of link
speed only support to 10G, the parameter 'current' will be a random
value in the scenario of higher link speed. In this case, incorrect
link speed of XL710 nic will be stored in the database.

Signed-off-by: Xu Binbin <xu.binbin1 at zte.com.cn>
Signed-off-by: Ian Stokes <ian.stokes at intel.com>


  Commit: 89c09c1cd1f03506831105881ac29ffae74341f3
      https://github.com/openvswitch/ovs/commit/89c09c1cd1f03506831105881ac29ffae74341f3
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2018-08-27 (Mon, 27 Aug 2018)

  Changed paths:
    M configure.ac
    M lib/netdev-dpdk.c
    M lib/netdev-dpdk.h
    M lib/netdev-dummy.c
    M lib/netdev-linux.c
    M lib/netdev-linux.h
    M lib/netdev-provider.h
    M lib/netdev-vport.c

  Log Message:
  -----------
  netdev: Clean up class initialization.

The macros are hard to read.  This makes it a little more readable.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Signed-off-by: Ian Stokes <ian.stokes at intel.com>


  Commit: 03ca6aa0dc0ee9b92c80eeb9a1ddc49073ad5db2
      https://github.com/openvswitch/ovs/commit/03ca6aa0dc0ee9b92c80eeb9a1ddc49073ad5db2
  Author: Ilya Maximets <i.maximets at samsung.com>
  Date:   2018-08-27 (Mon, 27 Aug 2018)

  Changed paths:
    M vswitchd/vswitch.xml

  Log Message:
  -----------
  vswitch.xml: Fix type of dpdk-init key.

This adds available modes to the man page.

CC: Kevin Traynor <ktraynor at redhat.com>
Fixes: 6d947d508a51 ("vswitch.xml: Update dpdk-init documentation.")
Signed-off-by: Ilya Maximets <i.maximets at samsung.com>
Acked-by: Kevin Traynor <ktraynor at redhat.com>
Signed-off-by: Ian Stokes <ian.stokes at intel.com>


  Commit: 9b4f08cdcaf253175edda088683bdd3db9e4c097
      https://github.com/openvswitch/ovs/commit/9b4f08cdcaf253175edda088683bdd3db9e4c097
  Author: Vishal Deep Ajmera <vishal.deep.ajmera at ericsson.com>
  Date:   2018-08-27 (Mon, 27 Aug 2018)

  Changed paths:
    M lib/dpif-netdev.c

  Log Message:
  -----------
  dpif-netdev: Avoid reordering of packets in a batch with same megaflow

OVS reads packets in batches from a given port and packets in the
batch are subjected to potentially 3 levels of lookups to identify
the datapath megaflow entry (or flow) associated with the packet.
Each megaflow entry has a dedicated buffer in which packets that match
the flow classification criteria are collected. This buffer helps OVS
perform batch processing for all packets associated with a given flow.

Each packet in the received batch is first subjected to lookup in the
Exact Match Cache (EMC). Each EMC entry will point to a flow. If the
EMC lookup is successful, the packet is moved from the rx batch to the
per-flow buffer.

Packets that did not match any EMC entry are rearranged in the rx batch
at the beginning and are now subjected to a lookup in the megaflow cache.
Packets that match a megaflow cache entry are *appended* to the per-flow
buffer.

Packets that do not match any megaflow entry are subjected to slow-path
processing through the upcall mechanism. This cannot change the order of
packets as by definition upcall processing is only done for packets
without matching megaflow entry.

The EMC entry match fields encompass all potentially significant header
fields, typically more than specified in the associated flow's match
criteria. Hence, multiple EMC entries can point to the same flow. Given
that per-flow batching happens at each lookup stage, packets belonging
to the same megaflow can get re-ordered because some packets match EMC
entries while others do not.

The following example can illustrate the issue better. Consider
following batch of packets (labelled P1 to P8) associated with a single
TCP connection and associated with a single flow. Let us assume that
packets with just the ACK bit set in TCP flags have been received in a
prior batch also and a corresponding EMC entry exists.

1. P1 (TCP Flag: ACK)
2. P2 (TCP Flag: ACK)
3. P3 (TCP Flag: ACK)
4. P4 (TCP Flag: ACK, PSH)
5. P5 (TCP Flag: ACK)
6. P6 (TCP Flag: ACK)
7. P7 (TCP Flag: ACK)
8. P8 (TCP Flag: ACK)

The megaflow classification criteria does not include TCP flags while
the EMC match criteria does. Thus, all packets other than P4 match
the existing EMC entry and are moved to the per-flow packet batch.
Subsequently, packet P4 is moved to the same per-flow packet batch as
a result of the megaflow lookup. Though the packets have all been
correctly classified as being associated with the same flow, the
packet order has not been preserved because of the per-flow batching
performed during the EMC lookup stage. This packet re-ordering has
performance implications for TCP applications.

This patch preserves the packet ordering by performing the per-flow
batching after both the EMC and megaflow lookups are complete. As an
optimization, packets are flow-batched in emc processing till any
packet in the batch has an EMC miss.

A new flow map is maintained to keep the original order of packet
along with flow information. Post fastpath processing, packets from
flow map are *appended* to per-flow buffer.

Signed-off-by: Vishal Deep Ajmera <vishal.deep.ajmera at ericsson.com>
Co-authored-by: Venkatesan Pradeep <venkatesan.pradeep at ericsson.com>
Signed-off-by: Venkatesan Pradeep <venkatesan.pradeep at ericsson.com>
Signed-off-by: Ian Stokes <ian.stokes at intel.com>


Compare: https://github.com/openvswitch/ovs/compare/418a7a84245f...9b4f08cdcaf2
      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.


More information about the git mailing list