DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Xueming(Steven) Li" <xuemingl@mellanox.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Olivier MATZ <olivier.matz@6wind.com>,
	dev@dpdk.org, "Wu, Jingjing" <jingjing.wu@intel.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Yongseok Koh <yskoh@mellanox.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
Date: Tue, 30 Jan 2018 21:21:20 +0100	[thread overview]
Message-ID: <3030421.JaM4VfFdR3@xps> (raw)
In-Reply-To: <VI1PR05MB16787998CBF96D88ACFB2EC0ACE40@VI1PR05MB1678.eurprd05.prod.outlook.com>

Xueming,

We already discussed privately some time ago about this API.
You got some questions from me, from Olivier and from Konstantin.
The next version should answer the questions asked.

When defining an API, the doxygen documentation must explain precisely
what must be set, when and why.
The documentation must be sufficient to allow users using it,
and to allow PMD writers to implement it.

I think it cannot be properly reviewed until we clearly understand
the API and the HW requirements/expectations.

Hope this helps to understand what is expected for integrating such API.


30/01/2018 18:54, Xueming(Steven) Li:

> > > > > > > > > > > This patch introduce new TX offloads flag for devices
> > > > > > > > > > > that support tunnel agnostic checksum and TSO offloads.
> > > > > > > > > > >
> > > > > > > > > > > The support from the device is for inner and outer
> > > > > > > > > > > checksums on IPV4/TCP/UDP and TSO for *any packet with
> > > > > > > > > > > the following
> > > > > > format*:
> > > > > > > > > > >
> > > > > > > > > > > < some headers > / [optional IPv4/IPv6] / [optional
> > > > > > > > > > > TCP/UDP] / <some
> > > > > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional
> > > > > > > > > > > headers> TCP/UDP]
> > > > > > > > > > >
> > > > > > > > > > > For example the following packets can use this feature:
> > > > > > > > > > >
> > > > > > > > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 /
> > > > > > > > > > > GRE / MPLS /
> > > > > > > > > > > ipv4 / udp
> > > > > > > > > >
> > > > > > > > > > So in terms of usage - what is the difference with
> > > > > > > > > > current TSO
> > > > > > types?
> > > > > > > > > > Konstantin
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Traditionally, HW only recognize "known" tunnel type, do
> > > > > > > > > TSO calculation based on L3/L4 headers known to tunnel
> > > > > > > > > type. For example, it must be
> > > > > > > > > L2 header after VXLAN, then L3. While this Generic
> > > > > > > > > offloading provides inner/outer L3/L4 header info(len and
> > > > > > > > > offset) to HW, and thus tunnel info become less important.
> > > > > > > > > Please note the MPLS over GRE tunnel in last example above.
> > > > > > > >
> > > > > > > > Ok, but I wonder when the user would like to do TSO on
> > > > > > > > tunnel packet, for this offload - would he need to do
> > > > > > > > something differently from what he has to do now:
> > > > > > > > raise PKT_TX_TCP_SEG and related flags, raise appropriate
> > > > > > > > PKT_TX_TUNNEL_* flag, fill l2_len, l3_len,
> > > > > > l4_len,tso_segsz,outer_l2_len,outer_l3_len?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major
> > > > > > > target of this new feature is to support "unknown" tunnel
> > > > > > > offloading, it
> > > > > > supports "known"
> > > > > > > tunnel type as well.
> > > > > >
> > > > > > Ok, but user would still need to set some flag to indicate that
> > > > > > this is a tunnel packet, and he wants TSO over it, right?
> > > > > > For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_*
> > > > > > (which actually means that user still have to know tunnel type
> > > > > > anyway?) But for some not defined tunnel type - what it would be?
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > As this feature target to TX path, Outer length as tunnel
> > > > > indication, leave it empty if tunnel not defined.
> > > >
> > > > Sorry, I didn't get it.
> > > > We need to let PMD know that it is a tunnel packet, right?
> > > > So we do need to raise PKT_TX_TUNNEL_* flag.
> > > >
> > >
> > > In my current code, mbuf.outer_l2_len is used to test tunnel packet.
> > > Agree a new tunnel flag would be better.
> > >
> > > > >
> > > > > But I think it good to define something like:
> > > > >  	PKT_TX_TUNNEL_GENERIC = PKT_TX_TUNNEL_MASK
> > > >
> > > > Yes, that's an option, I would probably name it PKT_TX_TUNNEL_UNKNOWN.
> > > >
> > > > > And a new flag PKT_TX_OUTER_UDP, how do you think?
> > > >
> > > > Not sure why do we need it?
> > > > HW still needs to know outer_l4_type to be able to work correctly?
> > >
> > > For tunnel type like vxlan, if outer UDP present, hw has to update UDP
> > > length field for each TSO packet segment.
> > 
> > I understand that, but I thought that HW is smart enough to parse the
> > header and recognize outer L3/L4 type  - as it is a 'generic' tunneling
> > (sorry I am not familiar with MLX HW at all).
> 
> It might be useful if the outer encapsulation not regular, for example MPLS.
> 
> > From what you saying - that assumption was wrong and user still  need to
> > provide some packet-type info at  least about outer headers, right?
> > So what else need to be set?
> > Probably PKT_TX_OUTER_IPV*, might be something else?
> 
> Sorry for the confusion, besides optional outer UDP type, still need PKT_TX_IPV4/6 and PKT_TX_OUTER_IPV4/6 

  reply	other threads:[~2018-01-30 20:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 14:11 [dpdk-dev] [PATCH 0/6] Support generic tunnel TX csum and TSO Xueming Li
2018-01-09 14:11 ` [dpdk-dev] [PATCH 1/6] net/mlx5: support tx swp tunnel offloading Xueming Li
2018-01-29 15:08   ` [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads Xueming Li
2018-01-29 16:49     ` Ananyev, Konstantin
2018-01-30  3:01       ` Xueming(Steven) Li
2018-01-30 13:28         ` Ananyev, Konstantin
2018-01-30 15:27           ` Xueming(Steven) Li
2018-01-30 15:33             ` Ananyev, Konstantin
2018-01-30 15:47               ` Xueming(Steven) Li
2018-01-30 16:02                 ` Ananyev, Konstantin
2018-01-30 16:10                   ` Xueming(Steven) Li
2018-01-30 17:04                     ` Ananyev, Konstantin
2018-01-30 17:54                       ` Xueming(Steven) Li
2018-01-30 20:21                         ` Thomas Monjalon [this message]
2018-01-31 15:20                           ` Xueming(Steven) Li
2018-01-31 15:17                         ` Xueming(Steven) Li
2018-01-29 15:08   ` [dpdk-dev] [PATCH v2 2/5] app/testpmd: testpmd support " Xueming Li
2018-01-29 15:08   ` [dpdk-dev] [PATCH v2 3/5] net/mlx5: separate TSO function in Tx data path Xueming Li
2018-01-29 15:08   ` [dpdk-dev] [PATCH v2 4/5] net/mlx5: support generic tunnel offloading Xueming Li
2018-01-29 15:08   ` [dpdk-dev] [PATCH v2 5/5] net/mlx5: allow max 192B TSO inline header length Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 0/7] support generic tunnel Tx checksum and TSO Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 1/7] ethdev: introduce Tx generic tunnel L3/L4 offload Xueming Li
2018-03-21  1:40     ` Yongseok Koh
2018-03-22 13:55       ` Xueming(Steven) Li
2018-03-28 12:52         ` Olivier Matz
2018-04-04  8:20           ` Xueming(Steven) Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 2/7] app/testpmd: testpmd support Tx generic tunnel offloads Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 3/7] app/testpmd: add more GRE extension to csum engine Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 4/7] app/testpmd: introduce VXLAN GPE to csum forwarding engine Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 5/7] net/mlx5: separate TSO function in Tx data path Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 6/7] net/mlx5: support generic tunnel offloading Xueming Li
2018-03-05 14:51   ` [dpdk-dev] [PATCH v3 7/7] net/mlx5: allow max 192B TSO inline header length Xueming Li
2018-04-08 12:32   ` [dpdk-dev] [PATCH v4 0/4] support Tx generic tunnel checksum and TSO Xueming Li
2018-04-17 14:43     ` [dpdk-dev] [PATCH v5 0/2] " Xueming Li
2018-04-17 14:47     ` [dpdk-dev] [PATCH v5 1/2] ethdev: introduce generic IP/UDP " Xueming Li
2018-04-17 21:21       ` Thomas Monjalon
2018-04-17 14:49     ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: testpmd support Tx generic tunnel offloads Xueming Li
2018-04-18 13:38     ` [dpdk-dev] [PATCH v6 0/2] support Tx generic tunnel checksum and TSO Xueming Li
2018-04-18 13:58     ` [dpdk-dev] [PATCH v6 1/2] ethdev: introduce generic IP/UDP " Xueming Li
2018-04-18 14:28       ` Thomas Monjalon
2018-04-18 16:45         ` Ananyev, Konstantin
2018-04-18 18:02           ` Thomas Monjalon
2018-04-23  9:55             ` Olivier Matz
2018-04-20 12:48       ` [dpdk-dev] [PATCH v7 0/2] support Tx generic " Xueming Li
2018-04-23 11:36         ` [dpdk-dev] [PATCH v8 " Xueming Li
2018-04-23 16:17           ` Ferruh Yigit
2018-04-23 11:36         ` [dpdk-dev] [PATCH v8 1/2] ethdev: introduce generic IP/UDP " Xueming Li
2018-04-23 11:49           ` Xueming Li
2018-04-23 11:36         ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: testpmd support Tx generic tunnel offloads Xueming Li
2018-04-20 12:48       ` [dpdk-dev] [PATCH v7 1/2] ethdev: introduce generic IP/UDP tunnel checksum and TSO Xueming Li
2018-04-23  9:59         ` Olivier Matz
2018-04-20 12:48       ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: testpmd support Tx generic tunnel offloads Xueming Li
2018-04-18 13:59     ` [dpdk-dev] [PATCH v6 " Xueming Li
2018-04-08 12:32   ` [dpdk-dev] [PATCH v4 1/4] ethdev: introduce generic IP/UDP tunnel checksum and TSO Xueming Li
2018-04-16 22:42     ` Thomas Monjalon
2018-04-17  7:53       ` Xueming(Steven) Li
2018-04-17  8:10         ` Thomas Monjalon
2018-04-08 12:32   ` [dpdk-dev] [PATCH v4 2/4] app/testpmd: testpmd support Tx generic tunnel offloads Xueming Li
2018-04-17 14:24     ` Iremonger, Bernard
2018-04-17 15:44       ` Xueming(Steven) Li
2018-04-08 12:32   ` [dpdk-dev] [PATCH v4 3/4] app/testpmd: add more GRE extension to csum engine Xueming Li
2018-04-16 22:45     ` Thomas Monjalon
2018-04-17  5:19       ` Xueming(Steven) Li
2018-04-08 12:32   ` [dpdk-dev] [PATCH v4 4/4] app/testpmd: introduce VXLAN GPE to csum forwarding engine Xueming Li
2018-04-16 22:46     ` Thomas Monjalon
2018-04-17 13:56       ` Iremonger, Bernard
2018-04-17 14:12         ` Xueming(Steven) Li
2018-01-09 14:11 ` [dpdk-dev] [PATCH 2/6] net/mlx5: allow max 192B WQE TSO inline header length Xueming Li
2018-01-09 14:11 ` [dpdk-dev] [PATCH 3/6] net/mlx5: add SWP PCI parameter for TX common tunnel offloads Xueming Li
2018-01-09 14:11 ` [dpdk-dev] [PATCH 4/6] ethdev: introduce " Xueming Li
2018-01-11 18:38   ` Ferruh Yigit
2018-01-16 17:10   ` Olivier Matz
2018-01-16 17:28     ` Xueming(Steven) Li
2018-01-16 19:06       ` Shahaf Shuler
2018-01-22 12:46         ` Olivier Matz
2018-01-22 20:06           ` Shahaf Shuler
2018-01-17  0:50   ` Yongseok Koh
2018-01-09 14:11 ` [dpdk-dev] [PATCH 5/6] net/mlx5: support " Xueming Li
2018-01-09 14:11 ` [dpdk-dev] [PATCH 6/6] app/testpmd: testpmd " Xueming Li
2018-01-16  3:09   ` Lu, Wenzhuo

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=3030421.JaM4VfFdR3@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=shahafs@mellanox.com \
    --cc=xuemingl@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).