mbox series

[ovs-dev,RFC,V4,0/9] netdev-dpdk: support multi-segment mbufs

Message ID 1512734518-103757-1-git-send-email-mark.b.kavanagh@intel.com
Headers show
Series netdev-dpdk: support multi-segment mbufs | expand

Message

Mark Kavanagh Dec. 8, 2017, 12:01 p.m. UTC
Overview
========
This patchset introduces support for multi-segment mbufs to OvS-DPDK.
Multi-segment mbufs are typically used when the size of an mbuf is
insufficient to contain the entirety of a packet's data. Instead, the
data is split across numerous mbufs, each carrying a portion, or
'segment', of the packet data. mbufs are chained via their 'next'
attribute (an mbuf pointer).

Use Cases
=========
i.  Handling oversized (guest-originated) frames, which are marked
    for hardware accelration/offload (TSO, for example).

    Packets which originate from a non-DPDK source may be marked for
    offload; as such, they may be larger than the permitted ingress
    interface's MTU, and may be stored in an oversized dp-packet. In
    order to transmit such packets over a DPDK port, their contents
    must be copied to a DPDK mbuf (via dpdk_do_tx_copy). However, in
    its current implementation, that function only copies data into
    a single mbuf; if the space available in the mbuf is exhausted,
    but not all packet data has been copied, then it is lost.
    Similarly, when cloning a DPDK mbuf, it must be considered
    whether that mbuf contains multiple segments. Both issues are
    resolved within this patchset.

ii. Handling jumbo frames.

    While OvS already supports jumbo frames, it does so by increasing
    mbuf size, such that the entirety of a jumbo frame may be handled
    in a single mbuf. This is certainly the preferred, and most
    performant approach (and remains the default). However, it places
    high demands on system memory; multi-segment mbufs may be
    prefereable for systems which are memory-constrained.

Enabling multi-segment mbufs
============================
Multi-segment and single-segment mbufs are mutually exclusive, and the
user must decide on which approach to adopt on init. The introduction
of a new OVSDB field, 'dpdk-multi-seg-mbufs', facilitates this.

This is a global boolean value, which determines how jumbo frames are
represented across all DPDK ports. In the absence of a user-supplied
value, 'dpdk-multi-seg-mbufs' defaults to false, i.e. multi-segment
mbufs must be explicitly enabled / single-segment mbufs remain the
default.

Setting the field is identical to setting existing DPDK-specific OVSDB
fields:

    ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
    ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x10
    ovs-vsctl set Open_vSwitch . other_config:dpdk-socket-mem=4096,0
==> ovs-vsctl set Open_vSwitch . other_config:dpdk-multi-seg-mbufs=true


Notes
=====
This patchset was generated and built against:
- Current HEAD of OvS master[1] + DPDK v17.11 support patchset[2]
- DPDK v17.11

[1] 159cc1f ("datapath-windows: Correct endianness for deleting zone.")
[2] https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341786.html

---

v4: - restructure patchset
    - account for 128B ARM cacheline when sizing mbufs

Mark Kavanagh (5):
  netdev-dpdk: fix mbuf sizing
  dp-packet: fix reset_packet for multi-seg mbufs
  dp-packet: fix put_uninit for multi-seg mbufs
  dp-packet: init specific mbuf fields to 0
  netdev-dpdk: support multi-segment jumbo frames

Michael Qiu (4):
  dp-packet: Fix data_len issue with multi-seg mbufs
  dp-packet: copy mbuf info for packet copy
  dp-packet: copy data from multi-seg. DPDK mbuf
  netdev-dpdk: copy large packet to multi-seg. mbufs

 NEWS                 |   1 +
 lib/dp-packet.c      |  51 ++++++++++++++++-
 lib/dp-packet.h      |  26 ++++-----
 lib/dpdk.c           |   7 +++
 lib/netdev-dpdk.c    | 156 ++++++++++++++++++++++++++++++++++++++++++---------
 lib/netdev-dpdk.h    |   1 +
 vswitchd/vswitch.xml |  20 +++++++
 7 files changed, 220 insertions(+), 42 deletions(-)

Comments

Chandran, Sugesh Dec. 8, 2017, 6:10 p.m. UTC | #1
Thank you Mark & Michael Qiu for this work.

I had looked at the patch series and have some high level comments as inline.

I would like to test these patch on some of the test scenarios.
so please send a proper patch series once the DPDK17.11 support is added in OVS.

Regards
_Sugesh


> -----Original Message-----
> From: Kavanagh, Mark B
> Sent: Friday, December 8, 2017 12:02 PM
> To: dev@openvswitch.org; qiudayu@chinac.com
> Cc: Stokes, Ian <ian.stokes@intel.com>; Loftus, Ciara <ciara.loftus@intel.com>;
> santosh.shukla@caviumnetworks.com; Chandran, Sugesh
> <sugesh.chandran@intel.com>; Kavanagh, Mark B
> <mark.b.kavanagh@intel.com>
> Subject: [ovs-dev][RFC PATCH V4 0/9] netdev-dpdk: support multi-segment
> mbufs
> 
> Overview
> ========
> This patchset introduces support for multi-segment mbufs to OvS-DPDK.
> Multi-segment mbufs are typically used when the size of an mbuf is insufficient
> to contain the entirety of a packet's data. Instead, the data is split across
> numerous mbufs, each carrying a portion, or 'segment', of the packet data.
> mbufs are chained via their 'next'
> attribute (an mbuf pointer).
> 
> Use Cases
> =========
> i.  Handling oversized (guest-originated) frames, which are marked
>     for hardware accelration/offload (TSO, for example).
> 
>     Packets which originate from a non-DPDK source may be marked for
>     offload; as such, they may be larger than the permitted ingress
>     interface's MTU, and may be stored in an oversized dp-packet. In
>     order to transmit such packets over a DPDK port, their contents
>     must be copied to a DPDK mbuf (via dpdk_do_tx_copy). However, in
>     its current implementation, that function only copies data into
>     a single mbuf; if the space available in the mbuf is exhausted,
>     but not all packet data has been copied, then it is lost.
>     Similarly, when cloning a DPDK mbuf, it must be considered
>     whether that mbuf contains multiple segments. Both issues are
>     resolved within this patchset.
> 
> ii. Handling jumbo frames.
> 
>     While OvS already supports jumbo frames, it does so by increasing
>     mbuf size, such that the entirety of a jumbo frame may be handled
>     in a single mbuf. This is certainly the preferred, and most
>     performant approach (and remains the default). However, it places
>     high demands on system memory; multi-segment mbufs may be
>     prefereable for systems which are memory-constrained.
> 
> Enabling multi-segment mbufs
> ============================
> Multi-segment and single-segment mbufs are mutually exclusive, and the user
> must decide on which approach to adopt on init. The introduction of a new
> OVSDB field, 'dpdk-multi-seg-mbufs', facilitates this.
> 
> This is a global boolean value, which determines how jumbo frames are
> represented across all DPDK ports. In the absence of a user-supplied value,
> 'dpdk-multi-seg-mbufs' defaults to false, i.e. multi-segment mbufs must be
> explicitly enabled / single-segment mbufs remain the default.
> 
> Setting the field is identical to setting existing DPDK-specific OVSDB
> fields:
> 
>     ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
>     ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x10
>     ovs-vsctl set Open_vSwitch . other_config:dpdk-socket-mem=4096,0
> ==> ovs-vsctl set Open_vSwitch . other_config:dpdk-multi-seg-mbufs=true
> 
> 
> Notes
> =====
> This patchset was generated and built against:
> - Current HEAD of OvS master[1] + DPDK v17.11 support patchset[2]
> - DPDK v17.11
> 
> [1] 159cc1f ("datapath-windows: Correct endianness for deleting zone.") [2]
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341786.html
> 
> ---
> 
> v4: - restructure patchset
>     - account for 128B ARM cacheline when sizing mbufs
> 
> Mark Kavanagh (5):
>   netdev-dpdk: fix mbuf sizing
>   dp-packet: fix reset_packet for multi-seg mbufs
>   dp-packet: fix put_uninit for multi-seg mbufs
>   dp-packet: init specific mbuf fields to 0
>   netdev-dpdk: support multi-segment jumbo frames
> 
> Michael Qiu (4):
>   dp-packet: Fix data_len issue with multi-seg mbufs
>   dp-packet: copy mbuf info for packet copy
>   dp-packet: copy data from multi-seg. DPDK mbuf
>   netdev-dpdk: copy large packet to multi-seg. mbufs
> 
>  NEWS                 |   1 +
>  lib/dp-packet.c      |  51 ++++++++++++++++-
>  lib/dp-packet.h      |  26 ++++-----
>  lib/dpdk.c           |   7 +++
>  lib/netdev-dpdk.c    | 156 ++++++++++++++++++++++++++++++++++++++++++---
> ------
>  lib/netdev-dpdk.h    |   1 +
>  vswitchd/vswitch.xml |  20 +++++++
>  7 files changed, 220 insertions(+), 42 deletions(-)
> 
> --
> 1.9.3
Mark Kavanagh Dec. 11, 2017, 11:22 a.m. UTC | #2
Thanks Sugesh,

I'll rebase today and send an updated version that addresses your comments.

Best,
Mark

>-----Original Message-----
>From: Chandran, Sugesh
>Sent: Friday, December 8, 2017 6:10 PM
>To: Kavanagh, Mark B <mark.b.kavanagh@intel.com>; dev@openvswitch.org;
>qiudayu@chinac.com
>Cc: Stokes, Ian <ian.stokes@intel.com>; Loftus, Ciara
><ciara.loftus@intel.com>; santosh.shukla@caviumnetworks.com
>Subject: RE: [ovs-dev][RFC PATCH V4 0/9] netdev-dpdk: support multi-segment
>mbufs
>
>Thank you Mark & Michael Qiu for this work.
>
>I had looked at the patch series and have some high level comments as inline.
>
>I would like to test these patch on some of the test scenarios.
>so please send a proper patch series once the DPDK17.11 support is added in
>OVS.
>
>Regards
>_Sugesh
>
>
>> -----Original Message-----
>> From: Kavanagh, Mark B
>> Sent: Friday, December 8, 2017 12:02 PM
>> To: dev@openvswitch.org; qiudayu@chinac.com
>> Cc: Stokes, Ian <ian.stokes@intel.com>; Loftus, Ciara
><ciara.loftus@intel.com>;
>> santosh.shukla@caviumnetworks.com; Chandran, Sugesh
>> <sugesh.chandran@intel.com>; Kavanagh, Mark B
>> <mark.b.kavanagh@intel.com>
>> Subject: [ovs-dev][RFC PATCH V4 0/9] netdev-dpdk: support multi-segment
>> mbufs
>>
>> Overview
>> ========
>> This patchset introduces support for multi-segment mbufs to OvS-DPDK.
>> Multi-segment mbufs are typically used when the size of an mbuf is
>insufficient
>> to contain the entirety of a packet's data. Instead, the data is split
>across
>> numerous mbufs, each carrying a portion, or 'segment', of the packet data.
>> mbufs are chained via their 'next'
>> attribute (an mbuf pointer).
>>
>> Use Cases
>> =========
>> i.  Handling oversized (guest-originated) frames, which are marked
>>     for hardware accelration/offload (TSO, for example).
>>
>>     Packets which originate from a non-DPDK source may be marked for
>>     offload; as such, they may be larger than the permitted ingress
>>     interface's MTU, and may be stored in an oversized dp-packet. In
>>     order to transmit such packets over a DPDK port, their contents
>>     must be copied to a DPDK mbuf (via dpdk_do_tx_copy). However, in
>>     its current implementation, that function only copies data into
>>     a single mbuf; if the space available in the mbuf is exhausted,
>>     but not all packet data has been copied, then it is lost.
>>     Similarly, when cloning a DPDK mbuf, it must be considered
>>     whether that mbuf contains multiple segments. Both issues are
>>     resolved within this patchset.
>>
>> ii. Handling jumbo frames.
>>
>>     While OvS already supports jumbo frames, it does so by increasing
>>     mbuf size, such that the entirety of a jumbo frame may be handled
>>     in a single mbuf. This is certainly the preferred, and most
>>     performant approach (and remains the default). However, it places
>>     high demands on system memory; multi-segment mbufs may be
>>     prefereable for systems which are memory-constrained.
>>
>> Enabling multi-segment mbufs
>> ============================
>> Multi-segment and single-segment mbufs are mutually exclusive, and the user
>> must decide on which approach to adopt on init. The introduction of a new
>> OVSDB field, 'dpdk-multi-seg-mbufs', facilitates this.
>>
>> This is a global boolean value, which determines how jumbo frames are
>> represented across all DPDK ports. In the absence of a user-supplied value,
>> 'dpdk-multi-seg-mbufs' defaults to false, i.e. multi-segment mbufs must be
>> explicitly enabled / single-segment mbufs remain the default.
>>
>> Setting the field is identical to setting existing DPDK-specific OVSDB
>> fields:
>>
>>     ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
>>     ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x10
>>     ovs-vsctl set Open_vSwitch . other_config:dpdk-socket-mem=4096,0
>> ==> ovs-vsctl set Open_vSwitch . other_config:dpdk-multi-seg-mbufs=true
>>
>>
>> Notes
>> =====
>> This patchset was generated and built against:
>> - Current HEAD of OvS master[1] + DPDK v17.11 support patchset[2]
>> - DPDK v17.11
>>
>> [1] 159cc1f ("datapath-windows: Correct endianness for deleting zone.") [2]
>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341786.html
>>
>> ---
>>
>> v4: - restructure patchset
>>     - account for 128B ARM cacheline when sizing mbufs
>>
>> Mark Kavanagh (5):
>>   netdev-dpdk: fix mbuf sizing
>>   dp-packet: fix reset_packet for multi-seg mbufs
>>   dp-packet: fix put_uninit for multi-seg mbufs
>>   dp-packet: init specific mbuf fields to 0
>>   netdev-dpdk: support multi-segment jumbo frames
>>
>> Michael Qiu (4):
>>   dp-packet: Fix data_len issue with multi-seg mbufs
>>   dp-packet: copy mbuf info for packet copy
>>   dp-packet: copy data from multi-seg. DPDK mbuf
>>   netdev-dpdk: copy large packet to multi-seg. mbufs
>>
>>  NEWS                 |   1 +
>>  lib/dp-packet.c      |  51 ++++++++++++++++-
>>  lib/dp-packet.h      |  26 ++++-----
>>  lib/dpdk.c           |   7 +++
>>  lib/netdev-dpdk.c    | 156 ++++++++++++++++++++++++++++++++++++++++++---
>> ------
>>  lib/netdev-dpdk.h    |   1 +
>>  vswitchd/vswitch.xml |  20 +++++++
>>  7 files changed, 220 insertions(+), 42 deletions(-)
>>
>> --
>> 1.9.3