DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dekel Peled <dekelp@mellanox.com>
To: Shahaf Shuler <shahafs@mellanox.com>,
	Ori Kam <orika@mellanox.com>, Yongseok Koh <yskoh@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] [RFC] net/mlx5: add support of LRO in MLX5 PMD
Date: Thu, 16 May 2019 12:13:12 +0000	[thread overview]
Message-ID: <VI1PR05MB42243AF968DA88A42EB60357B60A0@VI1PR05MB4224.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <VI1PR05MB4224DBA75435A46F1A3EAD14B6090@VI1PR05MB4224.eurprd05.prod.outlook.com>

Introduction:
LRO (Large Receive Offload) is intended to reduce host CPU overhead when processing Rx TCP packets.
LRO works by aggregating multiple incoming packets from a single stream into a larger buffer, before they
are passed higher up the networking stack. Thus reducing the number of packets that have to be processed.

Use:
MLX5 PMD will query the HCA capabilities on initialization to check if LRO is supported and can be used.
LRO in MLX5 PMD is intended for use by applications using a relatively small number of flows.
LRO support can be enabled per port.
Multiple simultaneous LRO sessions will be supported, using multiple RQs per DPDK Rx queue.
In each LRO session, packets of the same flow will be coalesced until one of the following occur:

  *   Buffer size limit is exceeded.
  *   Session timeout is exceeded.
  *   Packet from a different flow is received on the same queue.
When LRO session ends the coalesced packet is passed to the PMD, which will update the header fields
before passing the packet to the application.
For efficient memory utilization, packets from all RQs will be stored in a single RMP per DPDK Rx queue,
utilizing MPRQ mechanism.
Support of Non-LRO flows will not be impacted.

Existing API:
Offload capability DEV_RX_OFFLOAD_TCP_LRO will be used to indicate device supports LRO.
testpmd command-line option "-enable-lro" will be used to request LRO feature enable on application start.
testpmd rx_offload "tcp_lro" on or off will be used to request LRO feature enable or disable during application runtime.
Offload flag PKT_RX_LRO will be used. This flag can be set in Rx mbuf to indicate this is a LRO coalesced packet.

New API:
PMD configuration parameter lro_timeout_usec will be added.
This parameter can be used by application to select LRO session timeout (in microseconds).
If this value is not specified, the minimal value supported by device will be used.

Comments are welcome.


Signed-off-by: Dekel Peled <dekelp@mellanox.com<mailto:dekelp@mellanox.com>>


           reply	other threads:[~2019-05-16 12:13 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <VI1PR05MB4224DBA75435A46F1A3EAD14B6090@VI1PR05MB4224.eurprd05.prod.outlook.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR05MB42243AF968DA88A42EB60357B60A0@VI1PR05MB4224.eurprd05.prod.outlook.com \
    --to=dekelp@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=orika@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).