[dpdk-dev] [PATCH v5] app/testpmd: enable the heavyweight mode TCP/IPv4 GRO
The GRO library provides two modes to reassemble packets. Currently, the
csum forwarding engine has supported to use the lightweight mode to
reassemble TCP/IPv4 packets. This patch introduces the heavyweight mode
for TCP/IPv4 GRO in the csum forwarding engine.
With the command "set port gro on|off", users can enable
TCP/IPv4 GRO for a given port. With the command "set gro flush ",
users can determine when the GROed TCP/IPv4 packets are flushed from
reassembly tables. With the command "show port gro", users can
display GRO configuration.
The GRO library doesn't re-calculate checksums for merged packets. If
users want the merged packets to have correct IP and TCP checksums,
please select HW IP checksum calculation and HW TCP checksum calculation
for the port which the merged packets are transmitted to.
Signed-off-by: Jiayu Hu
Reviewed-by: Ferruh Yigit
Tested-by: Yao Lei
---
changes in v5:
- fix port_id type conflict
changes in v4:
- fix unchecking the min value of 'cycle' bug in setup_gro_flush_cycles
- update the context of the testpmd document and commit logs
changes in v3:
- remove "heavyweight mode" and "lightweight mode" from GRO commands
- combine two patches into one
- use consistent help string for GRO commands
- remove the unnecessary command "gro set (max_flow_num)
(max_item_num_per_flow) (port_id)"
changes in v2:
- use "set" and "show" as the root level command
- add a new command to show GRO configuration
- fix l2_len/l3_len/l4_len unset etc. bugs
app/test-pmd/cmdline.c | 206
app/test-pmd/config.c | 68 +++--
app/test-pmd/csumonly.c | 31 -
app/test-pmd/testpmd.c | 19 ++-
app/test-pmd/testpmd.h | 16 ++-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 50 +--
6 files changed, 270 insertions(+), 120 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 91766bc..516fc89 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -427,13 +427,16 @@ static void cmd_help_long_parsed(void *parsed_result,
"tso show (portid)"
"Display the status of TCP Segmentation
Offload.\n\n"
- "gro (on|off) (port_id)"
+ "set port (port_id) gro on|off\n"
"Enable or disable Generic Receive Offload in"
" csum forwarding engine.\n\n"
- "gro set (max_flow_num) (max_item_num_per_flow)
(port_id)\n"
- "Set max flow number and max packet number per-flow"
- " for GRO.\n\n"
+ "show port (port_id) gro\n"
+ "Display GRO configuration.\n\n"
+
+ "set gro flush (cycles)\n"
+ "Set the cycle to flush GROed packets from"
+ " reassembly tables.\n\n"
"set fwd (%s)\n"
"Set packet forwarding mode.\n\n"
@@ -3868,115 +3871,145 @@ cmdline_parse_inst_t cmd_tunnel_tso_show = {
};
/* *** SET GRO FOR A PORT *** */
-struct cmd_gro_result {
+struct cmd_gro_enable_result {
+ cmdline_fixed_string_t cmd_set;
+ cmdline_fixed_string_t cmd_port;
cmdline_fixed_string_t cmd_keyword;
- cmdline_fixed_string_t mode;
- uint8_t port_id;
+ cmdline_fixed_string_t cmd_onoff;
+ portid_t cmd_pid;
};
static void
-cmd_enable_gro_parsed(void *parsed_result,
+cmd_gro_enable_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
__attribute__((unused)) void *data)
{
- struct cmd_gro_result *res;
+ struct cmd_gro_enable_result *res;
res = parsed_result;
- setup_gro(res->mode, res->port_id);
-}
-
-cmdline_parse_token_string_t cmd_gro_keyword =
- TOKEN_STRING_INITIALIZER(struct cmd_gro_result,
+ if (!strcmp(res->cmd_keyword, "gro"))
+ setup_gro(res->cmd_onoff, res->cmd_pid);
+}
+
+cmdline_parse_token_string_t cmd_gro_enable_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
+ cmd_set, "set");
+cmdline_parse_token_string_t cmd_gro_enable_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
+ cmd_keyword, "port");
+cmdline_parse_token_num_t cmd_gro_enable_pid =
+ TOKEN_NUM_INITIALIZER(struct cmd_gro_enable_result,
+ cmd_pid, UINT16);
+cmdline_parse_token_string_t cmd_gro_enable_keyword =
+ TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
cmd_keyword, "gro");
-cmdline_parse_token_string_t cmd_gro_mode =
- TOKEN_STRING_INITIALIZER(struct cmd_gro_result,
- mode, "on#off");
-cmdline_parse_token_num_t cmd_gro_pid =
- TOKEN_NUM_INITIALIZER(struct cmd_gro_result,
-
Re: [dpdk-dev] [PATCH v5] app/testpmd: enable the heavyweight mode TCP/IPv4 GRO
On 10/7/2017 8:45 AM, Jiayu Hu wrote: > The GRO library provides two modes to reassemble packets. Currently, the > csum forwarding engine has supported to use the lightweight mode to > reassemble TCP/IPv4 packets. This patch introduces the heavyweight mode > for TCP/IPv4 GRO in the csum forwarding engine. > > With the command "set port gro on|off", users can enable > TCP/IPv4 GRO for a given port. With the command "set gro flush ", > users can determine when the GROed TCP/IPv4 packets are flushed from > reassembly tables. With the command "show port gro", users can > display GRO configuration. > > The GRO library doesn't re-calculate checksums for merged packets. If > users want the merged packets to have correct IP and TCP checksums, > please select HW IP checksum calculation and HW TCP checksum calculation > for the port which the merged packets are transmitted to. > > Signed-off-by: Jiayu Hu > Reviewed-by: Ferruh Yigit > Tested-by: Yao Lei Applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH v2] eal: enable vfio independent of no PCI flag
In case no_pci is configured, other buses e.g. fslmc bus will
still need the the vfio to be enabled.
Signed-off-by: Hemant Agrawal
---
v2: enabled VFIO, independent of no-pci flag as suggested by Thomas
lib/librte_eal/linuxapp/eal/eal.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 28bc46b..76c980c 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -733,10 +733,8 @@ static int rte_eal_vfio_setup(void)
{
int vfio_enabled = 0;
- if (!internal_config.no_pci) {
- pci_vfio_enable();
- vfio_enabled |= pci_vfio_is_enabled();
- }
+ pci_vfio_enable();
+ vfio_enabled |= pci_vfio_is_enabled();
if (vfio_enabled) {
--
2.7.4
Re: [dpdk-dev] [PATCH] eal: fslmc bus need vfio enabled for non PCI case as well
On 10/6/2017 10:38 PM, Thomas Monjalon wrote:
06/10/2017 18:22, Hemant Agrawal:
On 10/6/2017 5:11 AM, Thomas Monjalon wrote:
13/07/2017 13:48, Hemant Agrawal:
In case no_pci is configured, fslmc bus will still need the
the vfio to be enabled.
Signed-off-by: Hemant Agrawal
---
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
+#ifdef RTE_LIBRTE_FSLMC_BUS
+ if (!vfio_enabled) {
+ if (!vfio_enable("vfio_fsl_mc"))
+ vfio_enabled = 1;
+ }
+#endif
It seems to be a hack.
VFIO is not only PCI.
Why --no-pci is impacting VFIO?
Anatoly?
At present there are only 2 users of VFIO. PCI and fsl-mc bus.
One options is that we always enable vfio irrespective of --no-pci flag.
My believe is that vfio-pci will be present in most system supporting
any other flavor of vfio (platform, fsl-mc etc).
The other option is what I proposed. i.e. if vfio is not already enabled
the platform is FSLMC bus, enable it.
Why not always enable it?
I agree. sent a v2 for this.
Regards,
Hemant
Re: [dpdk-dev] [PATCH v2] eal: enable vfio independent of no PCI flag
07/10/2017 13:20, Hemant Agrawal:
> In case no_pci is configured, other buses e.g. fslmc bus will
> still need the the vfio to be enabled.
>
> Signed-off-by: Hemant Agrawal
> ---
> v2: enabled VFIO, independent of no-pci flag as suggested by Thomas
[...]
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -733,10 +733,8 @@ static int rte_eal_vfio_setup(void)
> {
> int vfio_enabled = 0;
>
> - if (!internal_config.no_pci) {
> - pci_vfio_enable();
> - vfio_enabled |= pci_vfio_is_enabled();
> - }
> + pci_vfio_enable();
> + vfio_enabled |= pci_vfio_is_enabled();
You are enabling vfio_pci.
This part could stay conditionned by no_pci.
I was thinking you need vfio without vfio_pci. Am I right?
If yes, I suggest to enable only vfio root module.
Re: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev)
07/10/2017 01:27, Mokhtar, Amr:
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday 5 October 2017 23:23
> > To: Mokhtar, Amr
> > Cc: dev@dpdk.org; f...@redhat.com; acon...@redhat.com; bl...@debian.org
> > Subject: Re: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev)
> >
> > 05/10/2017 23:55, Mokhtar, Amr:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > 03/10/2017 16:29, Mokhtar, Amr:
> > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > > > 25/08/2017 15:46, Amr Mokhtar:
> > > > > > > +int
> > > > > > > +rte_bbdev_configure(uint8_t dev_id, uint16_t num_queues,
> > > > > > > + const struct rte_bbdev_conf *conf);
> > > > > >
> > > > > > I am not convinced by the "configure all" function in ethdev.
> > > > > > We break the ABI each time we add a new feature to configure.
> > > > > > And it does not really help to have all configurations in one
> > > > > > struct.
> > > > > > Would you mind to split the struct rte_bbdev_conf and split the
> > > > > > function accordingly?
> > > > >
> > > > > There is nothing to split tbh. The only parameter it has is the
> > > > > socket_id.
> > > > > And in fact, it's optional, can be null. The only config we need is
> > num_queues.
> > > >
> > > > Indeed, there is nothing in this struct.
> > > > If you need only to allocate queues, you just have to rename this
> > > > function.
> > > >
> > > > > I don't see in the near future that we may need to add more config
> > > > > params.
> > > > > As a side, in the time of the implementation we were trying to
> > > > > avoid any diversions from the current design ideology of ethdev and
> > cryptodev.
> > > >
> > > > There is no ideology in ethdev, just some mistakes ;)
> > > >
> > > > > Can we leave it for consideration with future releases?
> > > >
> > > > No it should be addressed from the beginning.
> > > >
> > > > When you will need to add something more to configure port-wise, you
> > > > should add a new function instead of breaking the ABI of the global conf
> > struct.
> > > > That's why the configure option should be more specialized.
> > > >
> > > > Distro people were complaining about ABI breakage last week.
> > > > This is exactly an example of how to avoid it from the beginning.
> > > >
> > >
> > > Ok, got your point. I was looking at it from an API-only standpoint.
> > > How about modifying it into?
> > > int
> > > rte_bbdev_setup_queues(uint16_t dev_id, uint16_t num_queues, int
> > > socket_id);
> >
> > Yes OK
> >
> > [...]
> > > > > > > +struct __rte_cache_aligned rte_bbdev {
> > > > > > > + rte_bbdev_enqueue_ops_t enqueue_ops; /**< Enqueue
> > function */
> > > > > > > + rte_bbdev_dequeue_ops_t dequeue_ops; /**< Dequeue
> > function */
> > > > > > > + const struct rte_bbdev_ops *dev_ops; /**< Functions
> > > > > > > +exported by PMD
> > > > > > */
> > > > > > > + struct rte_bbdev_data *data; /**< Pointer to device data */
> > > > > > > + bool attached; /**< If device is currently attached or not
> > > > > > > +*/
> > > > > >
> > > > > > What "attached" means?
> > > > > > I'm afraid you are trying to manage hotplug in the wrong layer.
> > > > >
> > > > > Hotplug is not supported in the current release.
> > > >
> > > > It is not answering the question.
> > > > What is an "attached" device?
> > >
> > > "Attached" means that the PCI device was probed and the bbdev device slot
> > > is
> > allocated.
> > > For software devices, means that a virtual bbdev device (vdev) is
> > > allocated for
> > bbdev.
> > > Same way the "attached" approach used in cryptodev.
> >
> > Not sure to understand.
> > If "attached" means "allocated", when is it false?
>
> Currently in bbdev, it is set to true and never goes false.
> As I said the Hotplug feature is not fully supported in the current version.
> I can remove that flag for now.
>
> But generally, it should be cleared to false when rte_pci_driver->remove
> function is called. (Hotplug?)
Hotplug is still a work in progress in DPDK.
Please remove this flag if it is useless.
We will add something if needed when hotplug support will be better designed.
> > [...]
> > > > > > > +/** Structure specifying a single operation */ struct
> > > > > > > rte_bbdev_op {
> > > > > > > + enum rte_bbdev_op_type type; /**< Type of this operation */
> > > > > > > + int status; /**< Status of operation that was performed */
> > > > > > > + struct rte_mempool *mempool; /**< Mempool which op
> > instance
> > > > > > > +is in
> > > > > > */
> > > > > > > + void *opaque_data; /**< Opaque pointer for user data */
> > > > > > > + /**
> > > > > > > + * Anonymous union of operation-type specific parameters.
> > > > > > > +When
> > > > > > allocated
> > > > > > > + * using rte_bbdev_op_pool_create(), space is allocated for the
> > > > > > > + * parameters at the end of each rte_bbdev_op structure, and
> > the
> > > > > > > + * pointers here point to it.
> > > > > > > + */
> > > > > > >
Re: [dpdk-dev] [git pull] virtio changes for 17.11-rc1
06/10/2017 08:45, Yuanhan Liu: > Hi Thomas, > > Please consider pulling following virtio changes for 17.11-rc1 at > git://dpdk.org/next/dpdk-next-virtiomaster There is a compilation error on ARM with "net/virtio: rationalize setting of Rx/Tx handlers" An include of rte_cpuflags.h is missing. There is also an error seen by clang in "vhost-user: add support to IOTLB miss slave requests" implicit conversion from enumeration type 'enum VhostUserSlaveRequest' to different enumeration type 'VhostUserRequest' This last error may be a real issue because VHOST_USER_SLAVE_IOTLB_MSG in VhostUserSlaveRequest can be understood as VHOST_USER_GET_FEATURES in VhostUserRequest. Please advise
[dpdk-dev] [PATCH v10 0/6] Support TCP/IPv4, VxLAN, and GRE GSO in DPDK
Generic Segmentation Offload (GSO) is a SW technique to split large packets into small ones. Akin to TSO, GSO enables applications to operate on large packets, thus reducing per-packet processing overhead. To enable more flexibility to applications, DPDK GSO is implemented as a standalone library. Applications explicitly use the GSO library to segment packets. This patch adds GSO support to DPDK for specific packet types: specifically, TCP/IPv4, VxLAN, and GRE. The first patch introduces the GSO API framework. The second patch adds GSO support for TCP/IPv4 packets (containing an optional VLAN tag). The third patch adds GSO support for VxLAN packets that contain outer IPv4, and inner TCP/IPv4 headers (plus optional inner and/or outer VLAN tags). The fourth patch adds GSO support for GRE packets that contain outer IPv4, and inner TCP/IPv4 headers (with optional outer VLAN tag). The fifth patch in the series enables TCP/IPv4, VxLAN, and GRE GSO in testpmd's checksum forwarding engine. The final patch in the series adds GSO documentation to the programmer's guide. Note that this patch set has dependency on the patch "app/testpmd: enable the heavyweight mode TCP/IPv4 GRO". http://dpdk.org/dev/patchwork/patch/29867/ Performance Testing === The performance of TCP/IPv4 GSO on a 10Gbps link is demonstrated using iperf. Setup for the test is described as follows: a. Connect 2 x 10Gbps physical ports (P0, P1), which are in the same machine, together physically. b. Launch testpmd with P0 and a vhost-user port, and use csum forwarding engine with "retry". c. Select IP and TCP HW checksum calculation for P0; select TCP HW checksum calculation for vhost-user port. d. Launch a VM with csum and tso offloading enabled. e. Run iperf-client on virtio-net port in the VM to send TCP packets. With enabling csum and tso, the VM can send large TCP/IPv4 packets (mss is up to 64KB). f. P1 is assigned to linux kernel and enabled kernel GRO. Run iperf-server on P1. We conduct three iperf tests: test-1: enable GSO for P0 in testpmd, and set max GSO segment length to 1514B. Run four iperf-client in the VM. test-2: enable TSO for P0 in testpmd, and set TSO segsz to 1514B. Run four iperf-client in the VM. test-3: disable GSO and TSO in testpmd. Run two iperf-client in the VM. Throughput of the above three tests: test-1: 9Gbps test-2: 9.5Gbps test-3: 3Mbps Functional Testing == Unlike TCP packets, VMs can't send large VxLAN or GRE packets. The max length of tunneled packets from VMs is 1514B. So current experiment method can't be used to measure VxLAN and GRE GSO performance, but simply test the functionality via setting small GSO segment length (e.g. 500B). VxLAN - To test VxLAN GSO functionality, we use the following setup: a. Connect 2 x 10Gbps physical ports (P0, P1), which are in the same machine, together physically. b. Launch testpmd with P0 and a vhost-user port, and use csum forwarding engine with "retry". c. Testpmd commands: - csum parse_tunnel on "P0" - csum parse_tunnel on "vhost-user port" - csum set outer-ip hw "P0" - csum set ip hw "P0" - csum set tcp hw "P0" - csum set tcp hw "vhost-user port" - set port "P0" gso on - set gso segsz 500 d. Launch a VM with csum and tso offloading enabled. e. Create a vxlan port for the virtio-net port in the VM. Run iperf-client on the VxLAN port, so TCP packets are VxLAN encapsulated. However, the max packet length is 1514B. f. P1 is assigned to linux kernel and kernel GRO is disabled. Similarly, create a VxLAN port for P1, and run iperf-server on the VxLAN port. In testpmd, we can see the length of all packets sent from P0 is smaller than or equal to 500B. Additionally, the packets arriving in P1 is encapsulated and is smaller than or equal to 500B. GRE --- The same process may be used to test GRE functionality, with the exception that the tunnel type created for both the guest's virtio-net, and the host's kernel interfaces is GRE: `ip tunnel add mode gre remote local ` As in the VxLAN testcase, the length of packets sent from P0, and received on P1, is less than 500B. Change log == v10: - fix portid type conflict (uint8_t -> uint16_t) in testpmd. - correct the RTE_GSO_FLAG_IPID_FIXED description: use 0 rather than !RTE_GSO_FLAG_IPID_FIXED to indicate using incremental IP ids. - rebase the GSO codes upon the patch "app/testpmd: enable the heavyweight mode TCP/IPv4 GRO" to fix the conflict issue in testpmd. v9: - fix testpmd build for i686 target - change log level from WARNING to DEBUG in the case of unsupported packet (rte_gso_segment()) v8: - resolve coding style infractions (indentation). - centralize invalid parameter checking for rte_gso_segment() into a single 'if' statement. - don't clear PKT_TX_TCP_SEG flag for packets that don't qualify for GSO on account of invalid params. - allow GSO for tunneled packets only via gso_ctx (by co
[dpdk-dev] [PATCH v10 1/6] gso: add Generic Segmentation Offload API framework
Generic Segmentation Offload (GSO) is a SW technique to split large packets into small ones. Akin to TSO, GSO enables applications to operate on large packets, thus reducing per-packet processing overhead. To enable more flexibility to applications, DPDK GSO is implemented as a standalone library. Applications explicitly use the GSO library to segment packets. To segment a packet requires two steps. The first is to set proper flags to mbuf->ol_flags, where the flags are the same as that of TSO. The second is to call the segmentation API, rte_gso_segment(). This patch introduces the GSO API framework to DPDK. rte_gso_segment() splits an input packet into small ones in each invocation. The GSO library refers to these small packets generated by rte_gso_segment() as GSO segments. Each of the newly-created GSO segments is organized as a two-segment MBUF, where the first segment is a standard MBUF, which stores a copy of packet header, and the second is an indirect MBUF which points to a section of data in the input packet. rte_gso_segment() reduces the refcnt of the input packet by 1. Therefore, when all GSO segments are freed, the input packet is freed automatically. Additionally, since each GSO segment has multiple MBUFs (i.e. 2 MBUFs), the driver of the interface which the GSO segments are sent to should support to transmit multi-segment packets. The GSO framework clears the PKT_TX_TCP_SEG flag for both the input packet, and all produced GSO segments in the event of success, since segmentation in hardware is no longer required at that point. Signed-off-by: Jiayu Hu Signed-off-by: Mark Kavanagh Acked-by: Konstantin Ananyev --- config/common_base | 5 ++ doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_11.rst | 1 + lib/Makefile | 2 + lib/librte_gso/Makefile| 49 +++ lib/librte_gso/rte_gso.c | 52 lib/librte_gso/rte_gso.h | 143 + lib/librte_gso/rte_gso_version.map | 7 ++ mk/rte.app.mk | 1 + 10 files changed, 262 insertions(+) create mode 100644 lib/librte_gso/Makefile create mode 100644 lib/librte_gso/rte_gso.c create mode 100644 lib/librte_gso/rte_gso.h create mode 100644 lib/librte_gso/rte_gso_version.map diff --git a/config/common_base b/config/common_base index ca47615..65c5e75 100644 --- a/config/common_base +++ b/config/common_base @@ -655,6 +655,11 @@ CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n CONFIG_RTE_LIBRTE_GRO=y # +# Compile GSO library +# +CONFIG_RTE_LIBRTE_GSO=y + +# # Compile librte_meter # CONFIG_RTE_LIBRTE_METER=y diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 19e0d4f..6512918 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -101,6 +101,7 @@ The public API headers are grouped by topics: [TCP](@ref rte_tcp.h), [UDP](@ref rte_udp.h), [GRO](@ref rte_gro.h), + [GSO](@ref rte_gso.h), [frag/reass] (@ref rte_ip_frag.h), [LPM IPv4 route] (@ref rte_lpm.h), [LPM IPv6 route] (@ref rte_lpm6.h), diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index 823554f..408f2e6 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -47,6 +47,7 @@ INPUT = doc/api/doxy-api-index.md \ lib/librte_ether \ lib/librte_eventdev \ lib/librte_gro \ + lib/librte_gso \ lib/librte_hash \ lib/librte_ip_frag \ lib/librte_jobstats \ diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index 4f92912..d75fec2 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -208,6 +208,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_ethdev.so.8 librte_eventdev.so.2 librte_gro.so.1 + librte_gso.so.1 librte_hash.so.2 librte_ip_frag.so.1 librte_jobstats.so.1 diff --git a/lib/Makefile b/lib/Makefile index 86caba1..3d123f4 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -108,6 +108,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder DEPDIRS-librte_reorder := librte_eal librte_mempool librte_mbuf DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump DEPDIRS-librte_pdump := librte_eal librte_mempool librte_mbuf librte_ether +DIRS-$(CONFIG_RTE_LIBRTE_GSO) += librte_gso +DEPDIRS-librte_gso := librte_eal librte_mbuf librte_ether librte_net ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni diff --git a/lib/librte_gso/Makefile b/lib/librte_gso/Makefile new file mode 100644 index 000..aeaacbc --- /dev/null +
[dpdk-dev] [PATCH v10 3/6] gso: add VxLAN GSO support
From: Mark Kavanagh
This patch adds a framework that allows GSO on tunneled packets.
Furthermore, it leverages that framework to provide GSO support for
VxLAN-encapsulated packets.
Supported VxLAN packets must have an outer IPv4 header (prepended by an
optional VLAN tag), and contain an inner TCP/IPv4 packet (with an optional
inner VLAN tag).
VxLAN GSO doesn't check if input packets have correct checksums and
doesn't update checksums for output packets. Additionally, it doesn't
process IP fragmented packets.
As with TCP/IPv4 GSO, VxLAN GSO uses a two-segment MBUF to organize each
output packet, which mandates support for multi-segment mbufs in the TX
functions of the NIC driver. Also, if a packet is GSOed, VxLAN GSO
reduces its MBUF refcnt by 1. As a result, when all of its GSO'd segments
are freed, the packet is freed automatically.
Signed-off-by: Mark Kavanagh
Signed-off-by: Jiayu Hu
Acked-by: Konstantin Ananyev
---
doc/guides/rel_notes/release_17_11.rst | 2 +
lib/librte_gso/Makefile| 1 +
lib/librte_gso/gso_common.h| 25 +++
lib/librte_gso/gso_tunnel_tcp4.c | 120 +
lib/librte_gso/gso_tunnel_tcp4.h | 75 +
lib/librte_gso/rte_gso.c | 14 +++-
6 files changed, 235 insertions(+), 2 deletions(-)
create mode 100644 lib/librte_gso/gso_tunnel_tcp4.c
create mode 100644 lib/librte_gso/gso_tunnel_tcp4.h
diff --git a/doc/guides/rel_notes/release_17_11.rst
b/doc/guides/rel_notes/release_17_11.rst
index 8f4a1e0..4c17207 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -71,6 +71,8 @@ New Features
ones (e.g. MTU is 1500B). Supported packet types are:
* TCP/IPv4 packets.
+ * VxLAN packets, which must have an outer IPv4 header, and contain
+an inner TCP/IPv4 packet.
The GSO library doesn't check if the input packets have correct
checksums, and doesn't update checksums for output packets.
diff --git a/lib/librte_gso/Makefile b/lib/librte_gso/Makefile
index 2be64d1..e6d41df 100644
--- a/lib/librte_gso/Makefile
+++ b/lib/librte_gso/Makefile
@@ -44,6 +44,7 @@ LIBABIVER := 1
SRCS-$(CONFIG_RTE_LIBRTE_GSO) += rte_gso.c
SRCS-$(CONFIG_RTE_LIBRTE_GSO) += gso_common.c
SRCS-$(CONFIG_RTE_LIBRTE_GSO) += gso_tcp4.c
+SRCS-$(CONFIG_RTE_LIBRTE_GSO) += gso_tunnel_tcp4.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_GSO)-include += rte_gso.h
diff --git a/lib/librte_gso/gso_common.h b/lib/librte_gso/gso_common.h
index a8ad638..95d54e7 100644
--- a/lib/librte_gso/gso_common.h
+++ b/lib/librte_gso/gso_common.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define IS_FRAGMENTED(frag_off) (((frag_off) & IPV4_HDR_OFFSET_MASK) != 0 \
|| ((frag_off) & IPV4_HDR_MF_FLAG) == IPV4_HDR_MF_FLAG)
@@ -49,6 +50,30 @@
#define IS_IPV4_TCP(flag) (((flag) & (PKT_TX_TCP_SEG | PKT_TX_IPV4)) == \
(PKT_TX_TCP_SEG | PKT_TX_IPV4))
+#define IS_IPV4_VXLAN_TCP4(flag) (((flag) & (PKT_TX_TCP_SEG | PKT_TX_IPV4 | \
+ PKT_TX_OUTER_IPV4 | PKT_TX_TUNNEL_VXLAN)) == \
+ (PKT_TX_TCP_SEG | PKT_TX_IPV4 | PKT_TX_OUTER_IPV4 | \
+PKT_TX_TUNNEL_VXLAN))
+
+/**
+ * Internal function which updates the UDP header of a packet, following
+ * segmentation. This is required to update the header's datagram length field.
+ *
+ * @param pkt
+ * The packet containing the UDP header.
+ * @param udp_offset
+ * The offset of the UDP header from the start of the packet.
+ */
+static inline void
+update_udp_header(struct rte_mbuf *pkt, uint16_t udp_offset)
+{
+ struct udp_hdr *udp_hdr;
+
+ udp_hdr = (struct udp_hdr *)(rte_pktmbuf_mtod(pkt, char *) +
+ udp_offset);
+ udp_hdr->dgram_len = rte_cpu_to_be_16(pkt->pkt_len - udp_offset);
+}
+
/**
* Internal function which updates the TCP header of a packet, following
* segmentation. This is required to update the header's 'sent' sequence
diff --git a/lib/librte_gso/gso_tunnel_tcp4.c b/lib/librte_gso/gso_tunnel_tcp4.c
new file mode 100644
index 000..5e8c8e5
--- /dev/null
+++ b/lib/librte_gso/gso_tunnel_tcp4.c
@@ -0,0 +1,120 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors ma
[dpdk-dev] [PATCH v10 2/6] gso: add TCP/IPv4 GSO support
This patch adds GSO support for TCP/IPv4 packets. Supported packets may include a single VLAN tag. TCP/IPv4 GSO doesn't check if input packets have correct checksums, and doesn't update checksums for output packets (the responsibility for this lies with the application). Additionally, TCP/IPv4 GSO doesn't process IP fragmented packets. TCP/IPv4 GSO uses two chained MBUFs, one direct MBUF and one indrect MBUF, to organize an output packet. Note that we refer to these two chained MBUFs as a two-segment MBUF. The direct MBUF stores the packet header, while the indirect mbuf simply points to a location within the original packet's payload. Consequently, use of the GSO library requires multi-segment MBUF support in the TX functions of the NIC driver. If a packet is GSO'd, TCP/IPv4 GSO reduces its MBUF refcnt by 1. As a result, when all of its GSOed segments are freed, the packet is freed automatically. Signed-off-by: Jiayu Hu Signed-off-by: Mark Kavanagh Acked-by: Konstantin Ananyev Tested-by: Lei Yao --- doc/guides/rel_notes/release_17_11.rst | 12 +++ lib/Makefile| 2 +- lib/librte_eal/common/include/rte_log.h | 1 + lib/librte_gso/Makefile | 2 + lib/librte_gso/gso_common.c | 153 lib/librte_gso/gso_common.h | 141 + lib/librte_gso/gso_tcp4.c | 102 + lib/librte_gso/gso_tcp4.h | 74 +++ lib/librte_gso/rte_gso.c| 53 ++- lib/librte_gso/rte_gso.h| 7 +- 10 files changed, 541 insertions(+), 6 deletions(-) create mode 100644 lib/librte_gso/gso_common.c create mode 100644 lib/librte_gso/gso_common.h create mode 100644 lib/librte_gso/gso_tcp4.c create mode 100644 lib/librte_gso/gso_tcp4.h diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index d75fec2..8f4a1e0 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -64,6 +64,18 @@ New Features * Support for Flow API * Support for Tx and Rx descriptor status functions +* **Added the Generic Segmentation Offload Library.** + + Added the Generic Segmentation Offload (GSO) library to enable + applications to split large packets (e.g. MTU is 64KB) into small + ones (e.g. MTU is 1500B). Supported packet types are: + + * TCP/IPv4 packets. + + The GSO library doesn't check if the input packets have correct + checksums, and doesn't update checksums for output packets. + Additionally, the GSO library doesn't process IP fragmented packets. + Resolved Issues --- diff --git a/lib/Makefile b/lib/Makefile index 3d123f4..5ecd1b3 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -109,7 +109,7 @@ DEPDIRS-librte_reorder := librte_eal librte_mempool librte_mbuf DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump DEPDIRS-librte_pdump := librte_eal librte_mempool librte_mbuf librte_ether DIRS-$(CONFIG_RTE_LIBRTE_GSO) += librte_gso -DEPDIRS-librte_gso := librte_eal librte_mbuf librte_ether librte_net +DEPDIRS-librte_gso := librte_eal librte_mbuf librte_ether librte_net librte_mempool ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h index ec8dba7..2fa1199 100644 --- a/lib/librte_eal/common/include/rte_log.h +++ b/lib/librte_eal/common/include/rte_log.h @@ -87,6 +87,7 @@ extern struct rte_logs rte_logs; #define RTE_LOGTYPE_CRYPTODEV 17 /**< Log related to cryptodev. */ #define RTE_LOGTYPE_EFD 18 /**< Log related to EFD. */ #define RTE_LOGTYPE_EVENTDEV 19 /**< Log related to eventdev. */ +#define RTE_LOGTYPE_GSO 20 /**< Log related to GSO. */ /* these log types can be used in an application */ #define RTE_LOGTYPE_USER1 24 /**< User-defined log type 1. */ diff --git a/lib/librte_gso/Makefile b/lib/librte_gso/Makefile index aeaacbc..2be64d1 100644 --- a/lib/librte_gso/Makefile +++ b/lib/librte_gso/Makefile @@ -42,6 +42,8 @@ LIBABIVER := 1 #source files SRCS-$(CONFIG_RTE_LIBRTE_GSO) += rte_gso.c +SRCS-$(CONFIG_RTE_LIBRTE_GSO) += gso_common.c +SRCS-$(CONFIG_RTE_LIBRTE_GSO) += gso_tcp4.c # install this header file SYMLINK-$(CONFIG_RTE_LIBRTE_GSO)-include += rte_gso.h diff --git a/lib/librte_gso/gso_common.c b/lib/librte_gso/gso_common.c new file mode 100644 index 000..ee75d4c --- /dev/null +++ b/lib/librte_gso/gso_common.c @@ -0,0 +1,153 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following discla
[dpdk-dev] [PATCH v10 4/6] gso: add GRE GSO support
From: Mark Kavanagh
This patch adds GSO support for GRE-tunneled packets. Supported GRE
packets must contain an outer IPv4 header, and inner TCP/IPv4 headers.
They may also contain a single VLAN tag. GRE GSO doesn't check if all
input packets have correct checksums and doesn't update checksums for
output packets. Additionally, it doesn't process IP fragmented packets.
As with VxLAN GSO, GRE GSO uses a two-segment MBUF to organize each
output packet, which requires multi-segment mbuf support in the TX
functions of the NIC driver. Also, if a packet is GSOed, GRE GSO reduces
its MBUF refcnt by 1. As a result, when all of its GSOed segments are
freed, the packet is freed automatically.
Signed-off-by: Mark Kavanagh
Signed-off-by: Jiayu Hu
Acked-by: Konstantin Ananyev
---
doc/guides/rel_notes/release_17_11.rst | 2 ++
lib/librte_gso/gso_common.h| 5 +
lib/librte_gso/gso_tunnel_tcp4.c | 14 ++
lib/librte_gso/rte_gso.c | 9 ++---
4 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/doc/guides/rel_notes/release_17_11.rst
b/doc/guides/rel_notes/release_17_11.rst
index 4c17207..6ab725f 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -73,6 +73,8 @@ New Features
* TCP/IPv4 packets.
* VxLAN packets, which must have an outer IPv4 header, and contain
an inner TCP/IPv4 packet.
+ * GRE packets, which must contain an outer IPv4 header, and inner
+TCP/IPv4 headers.
The GSO library doesn't check if the input packets have correct
checksums, and doesn't update checksums for output packets.
diff --git a/lib/librte_gso/gso_common.h b/lib/librte_gso/gso_common.h
index 95d54e7..145ea49 100644
--- a/lib/librte_gso/gso_common.h
+++ b/lib/librte_gso/gso_common.h
@@ -55,6 +55,11 @@
(PKT_TX_TCP_SEG | PKT_TX_IPV4 | PKT_TX_OUTER_IPV4 | \
PKT_TX_TUNNEL_VXLAN))
+#define IS_IPV4_GRE_TCP4(flag) (((flag) & (PKT_TX_TCP_SEG | PKT_TX_IPV4 | \
+ PKT_TX_OUTER_IPV4 | PKT_TX_TUNNEL_GRE)) == \
+ (PKT_TX_TCP_SEG | PKT_TX_IPV4 | PKT_TX_OUTER_IPV4 | \
+PKT_TX_TUNNEL_GRE))
+
/**
* Internal function which updates the UDP header of a packet, following
* segmentation. This is required to update the header's datagram length field.
diff --git a/lib/librte_gso/gso_tunnel_tcp4.c b/lib/librte_gso/gso_tunnel_tcp4.c
index 5e8c8e5..8d0cfd7 100644
--- a/lib/librte_gso/gso_tunnel_tcp4.c
+++ b/lib/librte_gso/gso_tunnel_tcp4.c
@@ -42,11 +42,13 @@ update_tunnel_ipv4_tcp_headers(struct rte_mbuf *pkt,
uint8_t ipid_delta,
struct tcp_hdr *tcp_hdr;
uint32_t sent_seq;
uint16_t outer_id, inner_id, tail_idx, i;
- uint16_t outer_ipv4_offset, inner_ipv4_offset, udp_offset, tcp_offset;
+ uint16_t outer_ipv4_offset, inner_ipv4_offset;
+ uint16_t udp_gre_offset, tcp_offset;
+ uint8_t update_udp_hdr;
outer_ipv4_offset = pkt->outer_l2_len;
- udp_offset = outer_ipv4_offset + pkt->outer_l3_len;
- inner_ipv4_offset = udp_offset + pkt->l2_len;
+ udp_gre_offset = outer_ipv4_offset + pkt->outer_l3_len;
+ inner_ipv4_offset = udp_gre_offset + pkt->l2_len;
tcp_offset = inner_ipv4_offset + pkt->l3_len;
/* Outer IPv4 header. */
@@ -63,9 +65,13 @@ update_tunnel_ipv4_tcp_headers(struct rte_mbuf *pkt, uint8_t
ipid_delta,
sent_seq = rte_be_to_cpu_32(tcp_hdr->sent_seq);
tail_idx = nb_segs - 1;
+ /* Only update UDP header for VxLAN packets. */
+ update_udp_hdr = (pkt->ol_flags & PKT_TX_TUNNEL_VXLAN) ? 1 : 0;
+
for (i = 0; i < nb_segs; i++) {
update_ipv4_header(segs[i], outer_ipv4_offset, outer_id);
- update_udp_header(segs[i], udp_offset);
+ if (update_udp_hdr)
+ update_udp_header(segs[i], udp_gre_offset);
update_ipv4_header(segs[i], inner_ipv4_offset, inner_id);
update_tcp_header(segs[i], tcp_offset, sent_seq, i < tail_idx);
outer_id++;
diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c
index 0a3ef11..f86e654 100644
--- a/lib/librte_gso/rte_gso.c
+++ b/lib/librte_gso/rte_gso.c
@@ -58,7 +58,8 @@ rte_gso_segment(struct rte_mbuf *pkt,
nb_pkts_out < 1 ||
gso_ctx->gso_size < RTE_GSO_SEG_SIZE_MIN ||
((gso_ctx->gso_types & (DEV_TX_OFFLOAD_TCP_TSO |
- DEV_TX_OFFLOAD_VXLAN_TNL_TSO)) == 0))
+ DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
+ DEV_TX_OFFLOAD_GRE_TNL_TSO)) == 0))
return -EINVAL;
if (gso_ctx->gso_size >= pkt->pkt_len) {
@@ -73,8 +74,10 @@ rte_gso_segment(struct rte_mbuf *pkt,
ipid_delta = (gso_ctx->flag != RTE_GSO_FLAG_IPID_FIXED);
ol_flags = pkt->ol_flags;
- if (IS_IPV4_VXLAN_TCP4(pkt->ol_flags)
- && (gso_ct
[dpdk-dev] [PATCH v10 5/6] app/testpmd: enable TCP/IPv4, VxLAN and GRE GSO
This patch adds GSO support to the csum forwarding engine. Oversized
packets transmitted over a GSO-enabled port will undergo segmentation
(with the exception of packet-types unsupported by the GSO library).
GSO support is disabled by default.
GSO support may be toggled on a per-port basis, using the command:
"set port gso on|off"
The maximum packet length (including the packet header and payload) for
GSO segments may be set with the command:
"set gso segsz "
Show GSO configuration for a given port with the command:
"show port gso"
Signed-off-by: Jiayu Hu
Signed-off-by: Mark Kavanagh
Acked-by: Konstantin Ananyev
---
app/test-pmd/cmdline.c | 180
app/test-pmd/config.c | 24
app/test-pmd/csumonly.c | 43 ++-
app/test-pmd/testpmd.c | 13 ++
app/test-pmd/testpmd.h | 10 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 46 +++
6 files changed, 312 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 516fc89..b2d5284 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -438,6 +438,17 @@ static void cmd_help_long_parsed(void *parsed_result,
"Set the cycle to flush GROed packets from"
" reassembly tables.\n\n"
+ "set port (port_id) gso (on|off)"
+ "Enable or disable Generic Segmentation Offload in"
+ " csum forwarding engine.\n\n"
+
+ "set gso segsz (length)\n"
+ "Set max packet length for output GSO segments,"
+ " including packet header and payload.\n\n"
+
+ "show port (port_id) gso\n"
+ "Show GSO configuration.\n\n"
+
"set fwd (%s)\n"
"Set packet forwarding mode.\n\n"
@@ -4014,6 +4025,172 @@ cmdline_parse_inst_t cmd_gro_flush = {
},
};
+/* *** ENABLE/DISABLE GSO *** */
+struct cmd_gso_enable_result {
+ cmdline_fixed_string_t cmd_set;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_keyword;
+ cmdline_fixed_string_t cmd_mode;
+ portid_t cmd_pid;
+};
+
+static void
+cmd_gso_enable_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_gso_enable_result *res;
+
+ res = parsed_result;
+ if (!strcmp(res->cmd_keyword, "gso"))
+ setup_gso(res->cmd_mode, res->cmd_pid);
+}
+
+cmdline_parse_token_string_t cmd_gso_enable_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_gso_enable_result,
+ cmd_set, "set");
+cmdline_parse_token_string_t cmd_gso_enable_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_gso_enable_result,
+ cmd_port, "port");
+cmdline_parse_token_string_t cmd_gso_enable_keyword =
+ TOKEN_STRING_INITIALIZER(struct cmd_gso_enable_result,
+ cmd_keyword, "gso");
+cmdline_parse_token_string_t cmd_gso_enable_mode =
+ TOKEN_STRING_INITIALIZER(struct cmd_gso_enable_result,
+ cmd_mode, "on#off");
+cmdline_parse_token_num_t cmd_gso_enable_pid =
+ TOKEN_NUM_INITIALIZER(struct cmd_gso_enable_result,
+ cmd_pid, UINT16);
+
+cmdline_parse_inst_t cmd_gso_enable = {
+ .f = cmd_gso_enable_parsed,
+ .data = NULL,
+ .help_str = "set port gso on|off",
+ .tokens = {
+ (void *)&cmd_gso_enable_set,
+ (void *)&cmd_gso_enable_port,
+ (void *)&cmd_gso_enable_pid,
+ (void *)&cmd_gso_enable_keyword,
+ (void *)&cmd_gso_enable_mode,
+ NULL,
+ },
+};
+
+/* *** SET MAX PACKET LENGTH FOR GSO SEGMENTS *** */
+struct cmd_gso_size_result {
+ cmdline_fixed_string_t cmd_set;
+ cmdline_fixed_string_t cmd_keyword;
+ cmdline_fixed_string_t cmd_segsz;
+ uint16_t cmd_size;
+};
+
+static void
+cmd_gso_size_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_gso_size_result *res = parsed_result;
+
+ if (test_done == 0) {
+ printf("Before setting GSO segsz, please first"
+ " stop fowarding\n");
+ return;
+ }
+
+ if (!strcmp(res->cmd_keyword, "gso") &&
+ !strcmp(res->cmd_segsz, "segsz")) {
+ if (res->cmd_size < RTE_GSO_SEG_SIZE_MIN)
+ printf("gso_size should be larger than %zu."
+ " Please input a legal value\n",
+ RTE_GSO_SEG_SIZE_MIN);
+
[dpdk-dev] [PATCH v10 6/6] doc: add GSO programmer's guide
From: Mark Kavanagh Add programmer's guide doc to explain the design and use of the GSO library. Signed-off-by: Mark Kavanagh Signed-off-by: Jiayu Hu Acked-by: John McNamara Acked-by: Konstantin Ananyev --- MAINTAINERS| 6 + .../generic_segmentation_offload_lib.rst | 256 +++ .../prog_guide/img/gso-output-segment-format.svg | 313 ++ doc/guides/prog_guide/img/gso-three-seg-mbuf.svg | 477 + doc/guides/prog_guide/index.rst| 1 + 5 files changed, 1053 insertions(+) create mode 100644 doc/guides/prog_guide/generic_segmentation_offload_lib.rst create mode 100644 doc/guides/prog_guide/img/gso-output-segment-format.svg create mode 100644 doc/guides/prog_guide/img/gso-three-seg-mbuf.svg diff --git a/MAINTAINERS b/MAINTAINERS index cd0d6bc..950ef5c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -654,6 +654,12 @@ M: Jiayu Hu F: lib/librte_gro/ F: doc/guides/prog_guide/generic_receive_offload_lib.rst +Generic Segmentation Offload +M: Jiayu Hu +M: Mark Kavanagh +F: lib/librte_gso/ +F: doc/guides/prog_guide/generic_segmentation_offload_lib.rst + Distributor M: Bruce Richardson M: David Hunt diff --git a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst new file mode 100644 index 000..5e78f16 --- /dev/null +++ b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst @@ -0,0 +1,256 @@ +.. BSD LICENSE +Copyright(c) 2017 Intel Corporation. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Intel Corporation nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +Generic Segmentation Offload Library + + +Overview + +Generic Segmentation Offload (GSO) is a widely used software implementation of +TCP Segmentation Offload (TSO), which reduces per-packet processing overhead. +Much like TSO, GSO gains performance by enabling upper layer applications to +process a smaller number of large packets (e.g. MTU size of 64KB), instead of +processing higher numbers of small packets (e.g. MTU size of 1500B), thus +reducing per-packet overhead. + +For example, GSO allows guest kernel stacks to transmit over-sized TCP segments +that far exceed the kernel interface's MTU; this eliminates the need to segment +packets within the guest, and improves the data-to-overhead ratio of both the +guest-host link, and PCI bus. The expectation of the guest network stack in this +scenario is that segmentation of egress frames will take place either in the NIC +HW, or where that hardware capability is unavailable, either in the host +application, or network stack. + +Bearing that in mind, the GSO library enables DPDK applications to segment +packets in software. Note however, that GSO is implemented as a standalone +library, and not via a 'fallback' mechanism (i.e. for when TSO is unsupported +in the underlying hardware); that is, applications must explicitly invoke the +GSO library to segment packets. The size of GSO segments ``(segsz)`` is +configurable by the application. + +Limitations +--- + +#. The GSO library doesn't check if input packets have correct checksums. + +#. In addition, the GSO library doesn't re-calculate checksums for segmented + packets (that task is left to the application). + +#. IP fragments are unsupported by the GSO library. + +#. The egress interface's driver must support multi-segment packets. + +#. Currently, the GS
Re: [dpdk-dev] [git pull] virtio changes for 17.11-rc1
07/10/2017 16:37, Thomas Monjalon: > 06/10/2017 08:45, Yuanhan Liu: > > Hi Thomas, > > > > Please consider pulling following virtio changes for 17.11-rc1 at > > git://dpdk.org/next/dpdk-next-virtiomaster > > There is a compilation error on ARM with > "net/virtio: rationalize setting of Rx/Tx handlers" > An include of rte_cpuflags.h is missing. > > There is also an error seen by clang in > "vhost-user: add support to IOTLB miss slave requests" > implicit conversion from enumeration type 'enum VhostUserSlaveRequest' > to different enumeration type 'VhostUserRequest' > > This last error may be a real issue because VHOST_USER_SLAVE_IOTLB_MSG in > VhostUserSlaveRequest can be understood as VHOST_USER_GET_FEATURES in > VhostUserRequest. > > Please advise One more error with 32-bit compilation this time: "vhost: postpone device creation until ring are mapped" lib/librte_vhost/vhost.c:147:13: error: cast to pointer from integer of different size Please work together to have a tree which can be compiled for ARM and x86, 32-bit or 64-bit, with gcc or clang.
Re: [dpdk-dev] Can xenvirt pmd work in xen guest (aka DomU) without xen-vhost in Dom0 ?
Thanks Jianfeng for taking time to reply. please allow me to briefly explain why I want to run dpdk on xen. our system is based on dpdk, which means we use dpdk as packet receive/transmit engine, and with integrated dpdk virtio/vmxnet3 driver, our system can run on KVM/VMware platform . this year, we have plan to run our system on AWS cloud, but I found that AWS uses xen as its virtualization platform, and the bus-info of nic is vif-x (x could be 0,1,2...), the driver used in kernel is vif. this should be para-virtualized nic used on xen. I don't know which dpdk drvier can manage this pv nic. then I see xenvirt, I think this driver can did this job, like virtio can manage virtio nic which is used on kvm. unfortunately, after some study work, I run testpmd successfully on xen, but no packets received. with the informain got from you, I know It's need to run vhost_xen at dom0 so that xenvirt at domU can work. but for my case, I have no change to run vhost_xen at dom0, because I only can operate my own domU. for this case, If I want to run system which is based on dpdk at domU, what should I do? appreciate any idea or suggestion from you. On Mon, Oct 2, 2017 at 7:50 AM, Tan, Jianfeng wrote: > > > On 9/30/2017 5:25 PM, Bill Bonaparte wrote: > >> Hi Jianfeng, >> Thank you for replying, I appreciate so much for this. >> we are trying to run our dpdk application on AWS cloud which use xen >> platform. >> for this case, what should I do to support AWS cloud ? >> Is there any way to do this ? >> > > Sorry, I don't have knowledge to answer this question as I don't know what > kind of net devices in AWS cloud. > > Thanks, > Jianfeng > >
[dpdk-dev] [PATCH v3 0/4] add crypto mrvl pmd driver
Hello, This patch series introduces crypto driver for Marvell Armada 7k/8k SoCs along with documentation and crypto pmd driver tests. Below you can find the list of features which crypto pmd supports: * Symmetric crypto * Sym operation chaining * AES CBC (128) * AES CBC (192) * AES CBC (256) * AES CTR (128) * AES CTR (192) * AES CTR (256) * 3DES CBC * 3DES CTR * MD5 * MD5 HMAC * SHA1 * SHA1 HMAC * SHA256 * SHA256 HMAC * SHA384 * SHA384 HMAC * SHA512 * SHA512 HMAC * AES GCM (128) Changes since v2: * Added MRVL CRYPTO PMD to the test-build.sh. * Updated release notes. * Updated cryptoperf documentation. * Removed cryptodev_mrvl_pmd driver alias. * Fixed min,max key sizes used by HMACs in capabilities table. * Renamed map file. * Updated documentation. Tomasz Duszynski (4): crypto/mrvl: add mrvl crypto pmd driver doc: add mrvl crypto pmd documentation maintainers: add maintainers for the mrvl crypto pmd test: add mrvl crypto pmd unit tests MAINTAINERS | 10 + config/common_base | 6 + devtools/test-build.sh | 4 + doc/guides/cryptodevs/features/mrvl.ini | 42 ++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/mrvl.rst | 198 ++ doc/guides/rel_notes/release_17_11.rst | 5 + doc/guides/tools/cryptoperf.rst | 1 + drivers/crypto/Makefile | 2 + drivers/crypto/mrvl/Makefile | 63 ++ drivers/crypto/mrvl/rte_mrvl_compat.h| 48 ++ drivers/crypto/mrvl/rte_mrvl_pmd.c | 869 +++ drivers/crypto/mrvl/rte_mrvl_pmd_ops.c | 776 drivers/crypto/mrvl/rte_mrvl_pmd_private.h | 121 drivers/crypto/mrvl/rte_pmd_mrvl_version.map | 3 + mk/rte.app.mk| 1 + test/test/test_cryptodev.c | 168 ++ test/test/test_cryptodev.h | 1 + test/test/test_cryptodev_aes_test_vectors.h | 72 ++- test/test/test_cryptodev_blockcipher.c | 9 +- test/test/test_cryptodev_blockcipher.h | 1 + test/test/test_cryptodev_des_test_vectors.h | 24 +- 22 files changed, 2392 insertions(+), 33 deletions(-) create mode 100644 doc/guides/cryptodevs/features/mrvl.ini create mode 100644 doc/guides/cryptodevs/mrvl.rst create mode 100644 drivers/crypto/mrvl/Makefile create mode 100644 drivers/crypto/mrvl/rte_mrvl_compat.h create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd.c create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd_ops.c create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd_private.h create mode 100644 drivers/crypto/mrvl/rte_pmd_mrvl_version.map -- 2.7.4
[dpdk-dev] [PATCH v3 1/4] crypto/mrvl: add mrvl crypto pmd driver
Add support for the Marvell Security Crypto Accelerator EIP197.
Driver is based on external, publicly available, Marvell MUSDK
library that provides access to the hardware with minimum overhead
and high performance.
Driver comes with support for the following features:
* Symmetric crypto
* Sym operation chaining
* AES CBC (128)
* AES CBC (192)
* AES CBC (256)
* AES CTR (128)
* AES CTR (192)
* AES CTR (256)
* 3DES CBC
* 3DES CTR
* MD5
* MD5 HMAC
* SHA1
* SHA1 HMAC
* SHA256
* SHA256 HMAC
* SHA384
* SHA384 HMAC
* SHA512
* SHA512 HMAC
* AES GCM (128)
Driver was engineered cooperatively by Semihalf and Marvell teams.
Semihalf:
Jacek Siuda
Tomasz Duszynski
Marvell:
Dmitri Epshtein
Natalie Samsonov
Signed-off-by: Jacek Siuda
Signed-off-by: Tomasz Duszynski
---
v3:
* Added MRVL CRYPTO PMD to the test-build.sh.
* Updated release notes.
* Updated cryptoperf documentation.
* Removed cryptodev_mrvl_pmd driver alias.
* Fixed min,max key sizes used by HMACs in capabilities table.
* Renamed map file.
config/common_base | 6 +
devtools/test-build.sh | 4 +
doc/guides/rel_notes/release_17_11.rst | 5 +
doc/guides/tools/cryptoperf.rst | 1 +
drivers/crypto/Makefile | 2 +
drivers/crypto/mrvl/Makefile | 63 ++
drivers/crypto/mrvl/rte_mrvl_compat.h| 48 ++
drivers/crypto/mrvl/rte_mrvl_pmd.c | 869 +++
drivers/crypto/mrvl/rte_mrvl_pmd_ops.c | 776
drivers/crypto/mrvl/rte_mrvl_pmd_private.h | 121
drivers/crypto/mrvl/rte_pmd_mrvl_version.map | 3 +
mk/rte.app.mk| 1 +
12 files changed, 1899 insertions(+)
create mode 100644 drivers/crypto/mrvl/Makefile
create mode 100644 drivers/crypto/mrvl/rte_mrvl_compat.h
create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd.c
create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd_ops.c
create mode 100644 drivers/crypto/mrvl/rte_mrvl_pmd_private.h
create mode 100644 drivers/crypto/mrvl/rte_pmd_mrvl_version.map
diff --git a/config/common_base b/config/common_base
index 4e4e7c1..745b239 100644
--- a/config/common_base
+++ b/config/common_base
@@ -524,6 +524,12 @@ CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER_DEBUG=n
CONFIG_RTE_LIBRTE_PMD_NULL_CRYPTO=y
#
+# Compile PMD for Marvell Crypto device
+#
+CONFIG_RTE_LIBRTE_PMD_MRVL_CRYPTO=n
+CONFIG_RTE_LIBRTE_PMD_MRVL_CRYPTO_DEBUG=n
+
+#
# Compile generic event device library
#
CONFIG_RTE_LIBRTE_EVENTDEV=y
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index c6dfaf0..d82e3f4 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -50,6 +50,7 @@ default_path=$PATH
# - LIBSSO_SNOW3G_PATH
# - LIBSSO_KASUMI_PATH
# - LIBSSO_ZUC_PATH
+# - LIBMUSDK_PATH
. $(dirname $(readlink -e $0))/load-devel-config
print_usage () {
@@ -133,6 +134,7 @@ reset_env ()
unset LIBSSO_KASUMI_PATH
unset LIBSSO_ZUC_PATH
unset PQOS_INSTALL_PATH
+ unset LIBMUSDK_PATH
}
config () #
@@ -193,6 +195,8 @@ config () #
test "$DPDK_DEP_SSL" != y || \
sed -ri's,(PMD_QAT=)n,\1y,' $1/.config
sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
+ test -z "$LIBMUSDK_PATH" || \
+ sed -ri's,(PMD_MRVL_CRYPTO=)n,\1y,' $1/.config
build_config_hook $1 $2 $3
# Explicit enabler/disabler (uppercase)
diff --git a/doc/guides/rel_notes/release_17_11.rst
b/doc/guides/rel_notes/release_17_11.rst
index 4f92912..340e162 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -64,6 +64,11 @@ New Features
* Support for Flow API
* Support for Tx and Rx descriptor status functions
+* **Added MRVL crypto PMD.**
+
+ A new crypto PMD has been added, which provides several ciphering and hashing
+ algorithms. All cryptography operations use the MUSDK library crypto API.
+
Resolved Issues
---
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 457f817..5105230 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -189,6 +189,7 @@ The following are the appication command-line options:
crypto_dpaa2_sec
crypto_armv8
crypto_scheduler
+ crypto_mrvl
* ``--optype ``
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 7a719b9..1d7db5b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -51,6 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_KASUMI) += kasumi
DEPDIRS-kasumi = $(core-libs)
DIRS-$(CONFIG_RTE_LIBRTE_PMD_ZUC) += zuc
DEPDIRS-zuc = $(core-libs)
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_MRVL_CRYPTO) += mrvl
+DEPDIRS-mrvl = $(core-libs)
DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL_CRYPTO) += null
DEPDIRS-null = $(core-libs)
DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC) += dpaa2_sec
diff --git a/drivers
[dpdk-dev] [PATCH v3 2/4] doc: add mrvl crypto pmd documentation
Add documentation for the MRVL CRYPTO PMD driver. Signed-off-by: Jacek Siuda Signed-off-by: Tomasz Duszynski --- v3: * Updated documentation. doc/guides/cryptodevs/features/mrvl.ini | 42 +++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/mrvl.rst | 198 3 files changed, 241 insertions(+) create mode 100644 doc/guides/cryptodevs/features/mrvl.ini create mode 100644 doc/guides/cryptodevs/mrvl.rst diff --git a/doc/guides/cryptodevs/features/mrvl.ini b/doc/guides/cryptodevs/features/mrvl.ini new file mode 100644 index 000..6d2fe6a --- /dev/null +++ b/doc/guides/cryptodevs/features/mrvl.ini @@ -0,0 +1,42 @@ +; Supported features of the 'mrvl' crypto driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Symmetric crypto = Y +Sym operation chaining = Y + +; +; Supported crypto algorithms of a default crypto driver. +; +[Cipher] +AES CBC (128) = Y +AES CBC (192) = Y +AES CBC (256) = Y +AES CTR (128) = Y +AES CTR (192) = Y +AES CTR (256) = Y +3DES CBC = Y +3DES CTR = Y + +; +; Supported authentication algorithms of a default crypto driver. +; +[Auth] +MD5 = Y +MD5 HMAC = Y +SHA1 = Y +SHA1 HMAC= Y +SHA256 = Y +SHA256 HMAC = Y +SHA384 = Y +SHA384 HMAC = Y +SHA512 = Y +SHA512 HMAC = Y +AES GMAC = Y + +; +; Supported AEAD algorithms of a default crypto driver. +; +[AEAD] +AES GCM (128) = Y diff --git a/doc/guides/cryptodevs/index.rst b/doc/guides/cryptodevs/index.rst index 361b82d..a8ee0eb 100644 --- a/doc/guides/cryptodevs/index.rst +++ b/doc/guides/cryptodevs/index.rst @@ -42,6 +42,7 @@ Crypto Device Drivers dpaa2_sec kasumi openssl +mrvl null scheduler snow3g diff --git a/doc/guides/cryptodevs/mrvl.rst b/doc/guides/cryptodevs/mrvl.rst new file mode 100644 index 000..d38bed0 --- /dev/null +++ b/doc/guides/cryptodevs/mrvl.rst @@ -0,0 +1,198 @@ +.. BSD LICENSE +Copyright(c) 2017 Semihalf. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + + * Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. + * Neither the name of Semihalf nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +MRVL Crypto Poll Mode Driver + + +The MRVL CRYPTO PMD (**librte_crypto_mrvl_pmd**) provides poll mode crypto driver +support by utilizing MUSDK library, which provides cryptographic operations +acceleration by using Security Acceleration Engine (EIP197) directly from +user-space with minimum overhead and high performance. + +Features + + +MRVL CRYPTO PMD has support for: + +* Symmetric crypto +* Sym operation chaining +* AES CBC (128) +* AES CBC (192) +* AES CBC (256) +* AES CTR (128) +* AES CTR (192) +* AES CTR (256) +* 3DES CBC +* 3DES CTR +* MD5 +* MD5 HMAC +* SHA1 +* SHA1 HMAC +* SHA256 +* SHA256 HMAC +* SHA384 +* SHA384 HMAC +* SHA512 +* SHA512 HMAC +* AES GCM (128) + +Limitations +--- + +* Hardware only supports scenarios where ICV (digest buffer) is placed just + after the authenticated data. Other placement will result in error. + +Installation + + +MRVL CRYPTO PMD driver compilation is disabled by default due to external dependencies. +Currently there are two driver specific compilation options in +``config/common_base`` available: + +- ``CONFIG_RTE_LIBRTE_MRVL_CRYPTO`` (default ``n``) + +Toggle compilation of the librte_pmd_mrvl driver. + +- ``CONFIG_RTE_LIBRTE_MRVL_CRYPTO_DEBUG`` (default ``n``) + +Toggle display of debugging messages. + +
[dpdk-dev] [PATCH v3 3/4] maintainers: add maintainers for the mrvl crypto pmd
Signed-off-by: Jacek Siuda Signed-off-by: Tomasz Duszynski --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 73b0c1d..e65be03 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -574,6 +574,16 @@ F: drivers/crypto/dpaa2_sec/ F: doc/guides/cryptodevs/dpaa2_sec.rst F: doc/guides/cryptodevs/features/dpaa2_sec.ini +MARVELL MRVL PMD +M: Jacek Siuda +M: Tomasz Duszynski +M: Dmitri Epshtein +M: Natalie Samsonov +M: Jianbo Liu +F: drivers/crypto/mrvl/ +F: doc/guides/cryptodevs/mrvl.rst +F: doc/guides/cryptodevs/mrvl.ini + SNOW 3G PMD M: Pablo de Lara F: drivers/crypto/snow3g/ -- 2.7.4
[dpdk-dev] [PATCH v3 4/4] test: add mrvl crypto pmd unit tests
Add unit tests for MRVL CRYPTO PMD driver.
Signed-off-by: Jacek Siuda
Signed-off-by: Tomasz Duszynski
---
test/test/test_cryptodev.c | 168
test/test/test_cryptodev.h | 1 +
test/test/test_cryptodev_aes_test_vectors.h | 72
test/test/test_cryptodev_blockcipher.c | 9 +-
test/test/test_cryptodev_blockcipher.h | 1 +
test/test/test_cryptodev_des_test_vectors.h | 24 ++--
6 files changed, 242 insertions(+), 33 deletions(-)
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index a4116c6..9fb6a2c 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -341,6 +341,28 @@ testsuite_setup(void)
}
}
+ /* Create a MRVL device if required */
+ if (gbl_driver_id == rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_MRVL_PMD))) {
+#ifndef RTE_LIBRTE_PMD_MRVL_CRYPTO
+ RTE_LOG(ERR, USER1, "CONFIG_RTE_LIBRTE_PMD_MRVL_CRYPTO must be"
+ " enabled in config file to run this testsuite.\n");
+ return TEST_FAILED;
+#endif
+ nb_devs = rte_cryptodev_device_count_by_driver(
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)));
+ if (nb_devs < 1) {
+ ret = rte_vdev_init(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD),
+ NULL);
+
+ TEST_ASSERT(ret == 0, "Failed to create "
+ "instance of pmd : %s",
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD));
+ }
+ }
+
#ifdef RTE_LIBRTE_PMD_CRYPTO_SCHEDULER
if (gbl_driver_id == rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_SCHEDULER_PMD))) {
@@ -1862,6 +1884,101 @@ test_AES_chain_armv8_all(void)
return TEST_SUCCESS;
}
+static int
+test_AES_chain_mrvl_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool,
+ ts_params->session_mpool,
+ ts_params->valid_devs[0],
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)),
+ BLKCIPHER_AES_CHAIN_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_AES_cipheronly_mrvl_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool,
+ ts_params->session_mpool,
+ ts_params->valid_devs[0],
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)),
+ BLKCIPHER_AES_CIPHERONLY_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_authonly_mrvl_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool,
+ ts_params->session_mpool,
+ ts_params->valid_devs[0],
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)),
+ BLKCIPHER_AUTHONLY_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_3DES_chain_mrvl_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool,
+ ts_params->session_mpool,
+ ts_params->valid_devs[0],
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)),
+ BLKCIPHER_3DES_CHAIN_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_3DES_cipheronly_mrvl_all(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ int status;
+
+ status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+ ts_params->op_mpool,
+ ts_params->session_mpool,
+ ts_params->valid_devs[0],
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_MRVL_PMD)),
+ BLKCIPHER_3DES_CIPHERONLY_TYPE);
+
+ TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+ return TEST_SUCCESS;
+}
+
/* * SNOW 3G Tests * */
static int
create_wireless_algo_hash_session(uint8_t dev_id,
@@ -8939,6 +9056,40 @@ static struct unit_test_suite cryptodev_armv8_testsuite
= {
[dpdk-dev] [PATCH v2] net/mlx5: fix deadlock due to buffered slots in Rx SW ring
When replenishing Rx ring, there're always buffered slots reserved between
consumed entries and HW owned entries. These have to be filled with fake
mbufs to protect from possible overflow rather than optimistically
expecting successful replenishment which can cause deadlock with
small-sized queue.
Fixes: 951649d21edf ("net/mlx5: fix overflow of Rx SW ring")
Cc: sta...@dpdk.org
Reported-by: Martin Weiser
Signed-off-by: Yongseok Koh
---
v2:
* Replace vector st/ld with regular assignment as performance gain is negligible
for the short loop. This is to make the function shareable with ARM NEON.
This patch actually reverts "net/mlx5: fix overflow of Rx SW ring". If possible,
these two can be squashed by disregrading the old one.
drivers/net/mlx5/mlx5_rxtx_vec_sse.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_sse.c
b/drivers/net/mlx5/mlx5_rxtx_vec_sse.c
index 075dce908..4de8b7333 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_sse.c
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_sse.c
@@ -548,7 +548,7 @@ rxq_replenish_bulk_mbuf(struct rxq *rxq, uint16_t n)
{
const uint16_t q_n = 1 << rxq->elts_n;
const uint16_t q_mask = q_n - 1;
- const uint16_t elts_idx = rxq->rq_ci & q_mask;
+ uint16_t elts_idx = rxq->rq_ci & q_mask;
struct rte_mbuf **elts = &(*rxq->elts)[elts_idx];
volatile struct mlx5_wqe_data_seg *wq = &(*rxq->wqes)[elts_idx];
unsigned int i;
@@ -566,6 +566,10 @@ rxq_replenish_bulk_mbuf(struct rxq *rxq, uint16_t n)
wq[i].addr = rte_cpu_to_be_64((uintptr_t)elts[i]->buf_addr +
RTE_PKTMBUF_HEADROOM);
rxq->rq_ci += n;
+ /* Prevent overflowing into consumed mbufs. */
+ elts_idx = rxq->rq_ci & q_mask;
+ for (i = 0; i < MLX5_VPMD_DESCS_PER_LOOP; ++i)
+ (*rxq->elts)[elts_idx + i] = &rxq->fake_mbuf;
rte_wmb();
*rxq->rq_db = rte_cpu_to_be_32(rxq->rq_ci);
}
@@ -639,13 +643,6 @@ rxq_cq_decompress_v(struct rxq *rxq,
RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, hash) !=
offsetof(struct rte_mbuf, rx_descriptor_fields1) + 12);
/*
-* Not to overflow elts array. Decompress next time after mbuf
-* replenishment.
-*/
- if (unlikely(mcqe_n + MLX5_VPMD_DESCS_PER_LOOP >
-(uint16_t)(rxq->rq_ci - rxq->cq_ci)))
- return;
- /*
* A. load mCQEs into a 128bit register.
* B. store rearm data to mbuf.
* C. combine data from mCQEs with rx_descriptor_fields1.
@@ -1035,10 +1032,8 @@ rxq_burst_v(struct rxq *rxq, struct rte_mbuf **pkts,
uint16_t pkts_n)
}
elts_idx = rxq->rq_pi & q_mask;
elts = &(*rxq->elts)[elts_idx];
- pkts_n = RTE_MIN(pkts_n - rcvd_pkt,
-(uint16_t)(rxq->rq_ci - rxq->cq_ci));
- /* Not to overflow pkts/elts array. */
- pkts_n = RTE_ALIGN_FLOOR(pkts_n, MLX5_VPMD_DESCS_PER_LOOP);
+ /* Not to overflow pkts array. */
+ pkts_n = RTE_ALIGN_FLOOR(pkts_n - rcvd_pkt, MLX5_VPMD_DESCS_PER_LOOP);
/* Not to cross queue end. */
pkts_n = RTE_MIN(pkts_n, q_n - elts_idx);
if (!pkts_n)
--
2.11.0
Re: [dpdk-dev] Mellanox ConnectX-5 crashes and mbuf leak
> On Oct 6, 2017, at 3:30 PM, Yongseok Koh wrote: > > Hi, Martin > > Even though I had done quite serious tests before sending out the patch, > I figured out deadlock could happen if the Rx queue size is smaller. It is 128 > by default in testpmd while I usually use 256. > > I've fixed the bug and submitted a new patch [1], which actually reverts the > previous patch. So, you can apply the attached with disregarding the old one. > > And I have also done extensive tests for this new patch but please let me know > your test results. > > [1] > "net/mlx5: fix deadlock due to buffered slots in Rx SW ring" > at http://dpdk.org/dev/patchwork/patch/29847 Hi Martin I've submitted v2 of the patch [1]. I just replaced vector insns with regular statements. This is just for ease of maintenance because I'm about to add vectorized PMD for ARM NEON. In terms of functionality and performance it is identical. Please proceed your testing with this and let me know the result. [1] [dpdk-dev,v2] net/mlx5: fix deadlock due to buffered slots in Rx SW ring , which is at http://dpdk.org/dev/patchwork/patch/29879/ Thanks, Yongseok
Re: [dpdk-dev] [PATCH v10 0/6] Support TCP/IPv4, VxLAN, and GRE GSO in DPDK
On 10/7/2017 3:56 PM, Jiayu Hu wrote: > Generic Segmentation Offload (GSO) is a SW technique to split large > packets into small ones. Akin to TSO, GSO enables applications to > operate on large packets, thus reducing per-packet processing overhead. > > To enable more flexibility to applications, DPDK GSO is implemented > as a standalone library. Applications explicitly use the GSO library > to segment packets. This patch adds GSO support to DPDK for specific > packet types: specifically, TCP/IPv4, VxLAN, and GRE. > > The first patch introduces the GSO API framework. The second patch > adds GSO support for TCP/IPv4 packets (containing an optional VLAN > tag). The third patch adds GSO support for VxLAN packets that contain > outer IPv4, and inner TCP/IPv4 headers (plus optional inner and/or > outer VLAN tags). The fourth patch adds GSO support for GRE packets > that contain outer IPv4, and inner TCP/IPv4 headers (with optional > outer VLAN tag). The fifth patch in the series enables TCP/IPv4, VxLAN, > and GRE GSO in testpmd's checksum forwarding engine. The final patch > in the series adds GSO documentation to the programmer's guide. > > Note that this patch set has dependency on the patch "app/testpmd: enable > the heavyweight mode TCP/IPv4 GRO". > http://dpdk.org/dev/patchwork/patch/29867/ > > Performance Testing > === > The performance of TCP/IPv4 GSO on a 10Gbps link is demonstrated using > iperf. Setup for the test is described as follows: > > a. Connect 2 x 10Gbps physical ports (P0, P1), which are in the same >machine, together physically. > b. Launch testpmd with P0 and a vhost-user port, and use csum >forwarding engine with "retry". > c. Select IP and TCP HW checksum calculation for P0; select TCP HW >checksum calculation for vhost-user port. > d. Launch a VM with csum and tso offloading enabled. > e. Run iperf-client on virtio-net port in the VM to send TCP packets. >With enabling csum and tso, the VM can send large TCP/IPv4 packets >(mss is up to 64KB). > f. P1 is assigned to linux kernel and enabled kernel GRO. Run >iperf-server on P1. > > We conduct three iperf tests: > > test-1: enable GSO for P0 in testpmd, and set max GSO segment length > to 1514B. Run four iperf-client in the VM. > test-2: enable TSO for P0 in testpmd, and set TSO segsz to 1514B. Run > four iperf-client in the VM. > test-3: disable GSO and TSO in testpmd. Run two iperf-client in the VM. > > Throughput of the above three tests: > > test-1: 9Gbps > test-2: 9.5Gbps > test-3: 3Mbps > > Functional Testing > == > Unlike TCP packets, VMs can't send large VxLAN or GRE packets. The max > length of tunneled packets from VMs is 1514B. So current experiment > method can't be used to measure VxLAN and GRE GSO performance, but simply > test the functionality via setting small GSO segment length (e.g. 500B). > > VxLAN > - > To test VxLAN GSO functionality, we use the following setup: > > a. Connect 2 x 10Gbps physical ports (P0, P1), which are in the same >machine, together physically. > b. Launch testpmd with P0 and a vhost-user port, and use csum forwarding >engine with "retry". > c. Testpmd commands: > - csum parse_tunnel on "P0" > - csum parse_tunnel on "vhost-user port" > - csum set outer-ip hw "P0" > - csum set ip hw "P0" > - csum set tcp hw "P0" > - csum set tcp hw "vhost-user port" > - set port "P0" gso on > - set gso segsz 500 > d. Launch a VM with csum and tso offloading enabled. > e. Create a vxlan port for the virtio-net port in the VM. Run iperf-client >on the VxLAN port, so TCP packets are VxLAN encapsulated. However, the >max packet length is 1514B. > f. P1 is assigned to linux kernel and kernel GRO is disabled. Similarly, >create a VxLAN port for P1, and run iperf-server on the VxLAN port. > > In testpmd, we can see the length of all packets sent from P0 is smaller > than or equal to 500B. Additionally, the packets arriving in P1 is > encapsulated and is smaller than or equal to 500B. > > GRE > --- > The same process may be used to test GRE functionality, with the exception > that > the tunnel type created for both the guest's virtio-net, and the host's kernel > interfaces is GRE: >`ip tunnel add mode gre remote local ` > > As in the VxLAN testcase, the length of packets sent from P0, and received on > P1, is less than 500B. > <...> > Jiayu Hu (3): > gso: add Generic Segmentation Offload API framework > gso: add TCP/IPv4 GSO support > app/testpmd: enable TCP/IPv4, VxLAN and GRE GSO > > Mark Kavanagh (3): > gso: add VxLAN GSO support > gso: add GRE GSO support > doc: add GSO programmer's guide Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 1/2] testpmd: allow to query any RETA size
On 7/10/2017 2:17 AM, jingjing.wu at intel.com (Wu, Jingjing) wrote: >> -Original Message- >> From: Yuanhan Liu [mailto:yliu at fridaylinux.org] >> Sent: Friday, July 7, 2017 2:02 PM >> To: dev at dpdk.org >> Cc: Wu, Jingjing ; Yuanhan Liu > fridaylinux.org> >> Subject: [PATCH 1/2] testpmd: allow to query any RETA size >> >> Currently, testpmd just allows to query the RETA info only when the >> required size equals to configured RETA size. >> >> This patch allows to query any RETA size <= the configured size. This >> helps when the RETA size is big (say 512) and when I just want to peak >> few RETA entries. >> >> Signed-off-by: Yuanhan Liu > > Acked-by: Jingjing Wu Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] Can xenvirt pmd work in xen guest (aka DomU) without xen-vhost in Dom0 ?
Thanks Jianfeng for taking time to reply. please allow me to briefly explain why I want to run dpdk on xen. our system is based on dpdk, which means we use dpdk as packet receive/transmit engine, and with integrated dpdk virtio/vmxnet3 driver, our system can run on KVM/VMware platform . this year, we have plan to run our system on AWS cloud, but I found that AWS uses xen as its virtualization platform, and the bus-info of nic is vif-x (x could be 0,1,2...), the driver used in kernel is vif. this should be para-virtualized nic used on xen. I don't know which dpdk drvier can manage this pv nic. then I see xenvirt, I think this driver can did this job, like virtio can manage virtio nic which is used on kvm. unfortunately, after some study work, I run testpmd successfully on xen, but no packets received. with the informain got from you, I know It's need to run vhost_xen at dom0 so that xenvirt at domU can work. but for my case, I have no change to run vhost_xen at dom0, because I only can operate my own domU. for this case, If I want to run system which is based on dpdk at domU, what should I do? appreciate any idea or suggestion from you. On Mon, Oct 2, 2017 at 7:50 AM, Tan, Jianfeng wrote: > > > On 9/30/2017 5:25 PM, Bill Bonaparte wrote: > >> Hi Jianfeng, >> Thank you for replying, I appreciate so much for this. >> we are trying to run our dpdk application on AWS cloud which use xen >> platform. >> for this case, what should I do to support AWS cloud ? >> Is there any way to do this ? >> > > Sorry, I don't have knowledge to answer this question as I don't know what > kind of net devices in AWS cloud. > > Thanks, > Jianfeng > >
