DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Guo, Jia" <jia.guo@intel.com>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ori Kam <orika@nvidia.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"Wang, Haiyue" <haiyue.wang@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Gregory Etelson <getelson@nvidia.com>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
	Bing Zhao <bingz@nvidia.com>
Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
Date: Tue, 12 Jan 2021 02:14:07 +0000
Message-ID: <7ef7738be8304c42a69edc0b23e33a79@intel.com> (raw)
In-Reply-To: <7526138.hoSOgffrVm@thomas>



> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 11, 2021 10:54 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Guo, Jia <jia.guo@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ori Kam
> <orika@nvidia.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>;
> maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; Bing Zhao <bingz@nvidia.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 11/01/2021 15:02, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 11/01/2021 12:26, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 10/01/2021 11:46, Ori Kam:
> > > > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > > >>> Yes the port number is free.
> > > > > > > > > >>> But isn't it more natural to specify this port
> > > > > > > > > >>> number as part of the rte_flow rule?
> > > > > > > > > >>
> > > > > > > > > >> I think if we have a rte_flow action type that can be
> > > > > > > > > >> used to set a packet's tunnel type xxx, like below
> > > > > > > > > >> #flow create eth/ipv4/udp port is 4789/... action
> > > > > > > > > >> set_tunnel_type VxLAN / end then we may replace it
> > > > > > > > > >> with rte_flow, but I'm not sure if it's necessary,
> > > > > > > > > >> please share if you have a better idea.
> > > > > > > >
> > > > > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > > > > Please check rte_flow_item_udp.
> > > > > > > > That's a basic of rte_flow.
> > > > > > >
> > > > > > > Its not about the pattern match, it's about the action, what
> > > > > > > we need is a rte_flow action to "define a packet's tunnel
> > > > > > > type", but we don't
> > > have.
> > > > >
> > > > > A packet type alone is meaningless.
> > > > > It is always associated to an action, this is what rte_flow does.
> > > >
> > > > As I mentioned in previous, this is a device (port) level
> > > > configuration, so it can
> > > only be configured by a PF driver or a privileged VF base on our security
> model.
> > > > A typical usage in a NFV environment could be:
> > > >
> > > > 1. A privileged VF (e.g. ice_dcf PMD) use
> > > > rte_eth_dev_udp_tunnel_port_add
> > > to create tunnel port for eCPRI, them this will impact on all VFs in the same
> PF.
> > > > 2. A normal VF driver can create rte_flow rule that match specific
> > > > patch for
> > > queue steering or apply RSS for eCPRI packets, but it DON'T have the
> > > permission to define the tunnel port.
> > >
> > > Whaooh! A normal Intel VF is not allowed to match the tunnel it
> > > wants if not enabled by a priviledged VF?
> >
> > > I would say it is a HW design flaw, but that's not the question.
> >
> > Why you think this is a design flaw? in real case, is it a typical
> > requirement that different VF need different tunnel port for eCPRI (or
> > VxLan) on the same PF?
> 
> They are different VFs, so why should they use the same UDP port?
> Anyway it doesn't need to be typical to be allowed.

Yes, of cause, your can support different UDP tunnel port for different VF, but there are lots of alternative ways to isolate VFs, its just not a big deal for most real use case.
The typical requirement is some customer want eCPRI with UDP port A, while another one want UDP port B, and our NIC is good enough to support both cases separately.
There are seldom cases that different eCPRI tunnel port need to be deployed on the same NIC or same port.
so from my view, it's a reasonable design compromise that lose minor software flexibility but get a more simplified firmware and save more hardware resource from unnecessary usage.

> 
> > I believe it's not necessary to make it as a per VF resource in most
> > cases, and I will be surprise if a driver that allow any VF to change
> > the share resource without any privilege control.
> 
> The thing is that a flow rule should not be a shared resource.
> In Intel devices, it seems the UDP port of a protocol is supposed to be shared
> with all VFs, but it looks a very specific assumption, or limitation.
> I wonder how we can document this and ask the user to call
> rte_eth_dev_udp_tunnel_port_add(), because of some devices.
> Anyway, this is currently poorly documented.

OK, let me check the document to see if anything we can improve.

> 
> > Btw I guess mlx NIC has more flexible way to handle ecpri tunnel, just
> > curious how it works, what's the expected result of below rules?
> >
> > 1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ...
> > to queue 0 2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ...
> to queue 1.
> 
> It should move the eCPRI packets to the right queue, taking into consideration
> the UDP port and the message type.
> Of course there may be some bugs :)

I guess it is not just some bugs, I saw below note in Mellanox latest MLX5 driver.
"eCPRI over UDP layer is not yet supported right now",  
but this is not the question, I believe your answers are all fit for the VxLan case :)

For VxLAN offload I note below statement from your user manual

*If you configure multiple UDP ports for offload and exceed the total number of ports supported by hardware, then those additional ports will
still function properly, but will not benefit from any of the stateless offloads. 

Looks like you have a port limitation, additional port that above this number will not work with offload like RSS/steering ...,that's fine.
So my understanding the port resource is not just a regular rule in your general flow table.
The questions is how many is the limitation ?  does each VF has its own resource pool? 
If they are shared, how do you manage these ports? 
What if one malicious VF used up all the tunnel ports, does another VF still get chance to create its own?

> 
> > So both 1234 and 5678 will be regarded as an ECPRI packet?
> 
> Yes, both should be considered eCPRI.
> 
> > Or only the first one will work?
> 
> I am not aware of such limitation.
> 
> > does dst udp port is always needed if an ecpri pattern is involved?
> 
> No, the UDP part is optional.
> 


  reply	other threads:[~2021-01-12  2:14 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16  8:58 [dpdk-dev] [dpdk-dev 21.02 0/5] enable UDP ecpri configure in dcf Jeff Guo
2020-12-16  8:58 ` [dpdk-dev] [dpdk-dev 21.02 1/5] ethdev: add new tunnel type for ecpri Jeff Guo
2020-12-23  9:28   ` Zhang, Qi Z
2020-12-16  8:58 ` [dpdk-dev] [dpdk-dev 21.02 2/5] net/ice/base: add new UDP " Jeff Guo
2020-12-16  8:58 ` [dpdk-dev] [dpdk-dev 21.02 3/5] net/ice: add ecpri package type Jeff Guo
2020-12-16  8:58 ` [dpdk-dev] [dpdk-dev 21.02 4/5] net/ice: enable ecpri tunnel port configure in dcf Jeff Guo
2020-12-16  8:58 ` [dpdk-dev] [dpdk-dev 21.02 5/5] app/testpmd: add new UDP tunnel port for ecpri Jeff Guo
2020-12-24  6:59 ` [dpdk-dev] [dpdk-dev v2 0/2] " Jeff Guo
2020-12-24  6:59   ` [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-06 22:12     ` Thomas Monjalon
2021-01-07  9:32       ` Guo, Jia
2021-01-07 10:09         ` Andrew Rybchenko
2021-01-07 10:11         ` Thomas Monjalon
2021-01-07 12:47           ` Zhang, Qi Z
2021-01-07 13:33             ` Thomas Monjalon
2021-01-07 13:45               ` David Marchand
2021-01-07 14:27                 ` Dodji Seketeli
2021-01-07 15:24               ` Zhang, Qi Z
2021-01-07 16:58                 ` Thomas Monjalon
2021-01-08  1:41                   ` Zhang, Qi Z
2021-01-08  8:57                     ` Ferruh Yigit
2021-01-08  9:29                       ` Andrew Rybchenko
2021-01-08 10:36                         ` Thomas Monjalon
2021-01-09  1:01                           ` Zhang, Qi Z
2021-01-10 10:46                             ` Ori Kam
2021-01-11  9:23                               ` Thomas Monjalon
2021-01-11 11:26                                 ` Zhang, Qi Z
2021-01-11 11:37                                   ` Thomas Monjalon
2021-01-11 14:02                                     ` Zhang, Qi Z
2021-01-11 14:53                                       ` Thomas Monjalon
2021-01-12  2:14                                         ` Zhang, Qi Z [this message]
2021-01-15 15:15                                           ` Thomas Monjalon
2021-01-08  9:22               ` Ferruh Yigit
2021-01-08 10:23                 ` Thomas Monjalon
2021-01-08 10:43                   ` Ferruh Yigit
2021-01-08 14:06                     ` Thomas Monjalon
2021-01-08 14:07                       ` Kinsella, Ray
2021-01-08 14:10                         ` Thomas Monjalon
2021-01-08 12:38                   ` Kinsella, Ray
2021-01-08 14:27                     ` Ferruh Yigit
2021-01-08 14:31                       ` Kinsella, Ray
2021-01-08 17:34                       ` Kinsella, Ray
2021-01-14 14:34     ` Ferruh Yigit
2021-01-15  2:51       ` Guo, Jia
2020-12-24  6:59   ` [dpdk-dev] [dpdk-dev v2 2/2] app/testpmd: add new UDP tunnel port " Jeff Guo
2021-01-14 14:33     ` Ferruh Yigit
2021-01-15  2:13       ` Guo, Jia
2020-12-24 13:40   ` [dpdk-dev] [dpdk-dev v2 0/2] " Zhang, Qi Z
2020-12-24  7:01 ` [dpdk-dev] [dpdk-dev v2 0/6] enable UDP ecpri configure in dcf Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 1/6] net/ice/base: add package PTYPE enable information Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 2/6] net/ice: refactor package type parsing Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 3/6] net/ice/base: add new UDP tunnel type for ecpri Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 4/6] net/ice: add PTYPE mapping " Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 5/6] net/iavf: " Jeff Guo
2020-12-24  7:01   ` [dpdk-dev] [dpdk-dev v2 6/6] net/ice: enable ecpri tunnel port configure in dcf Jeff Guo
2021-01-12  9:32 ` [dpdk-dev] [dpdk-dev v3 0/3] net/ice: refactor PTYPE parsing Jeff Guo
2021-01-12  9:32   ` [dpdk-dev] [dpdk-dev v3 1/3] net/ice/base: add package PTYPE enable information Jeff Guo
2021-01-12  9:32   ` [dpdk-dev] [dpdk-dev v3 2/3] net/ice/base: add PTYPE value Jeff Guo
2021-01-12  9:32   ` [dpdk-dev] [dpdk-dev v3 3/3] net/ice: refactor PTYPE parsing Jeff Guo
2021-01-13  5:31 ` [dpdk-dev] [dpdk-dev v4 0/2] " Jeff Guo
2021-01-13  5:31   ` [dpdk-dev] [dpdk-dev v4 1/2] net/ice/base: add PTYPE value Jeff Guo
2021-01-13  5:31   ` [dpdk-dev] [dpdk-dev v4 2/2] net/ice: refactor PTYPE parsing Jeff Guo
2021-01-13  6:07   ` [dpdk-dev] [dpdk-dev v4 0/2] " Zhang, Qi Z
2021-01-13 14:05 ` [dpdk-dev] [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf Jeff Guo
2021-01-13 14:05   ` [dpdk-dev] [dpdk-dev v3 1/3] net/ice: add PTYPE mapping for ecpri Jeff Guo
2021-01-13 14:05   ` [dpdk-dev] [dpdk-dev v3 2/3] net/iavf: " Jeff Guo
2021-01-13 14:05   ` [dpdk-dev] [dpdk-dev v3 3/3] net/ice: enable ecpri tunnel port configure in dcf Jeff Guo
2021-01-14  4:18   ` [dpdk-dev] [dpdk-dev v3 0/3] enable UDP ecpri " Zhang, Qi Z
2021-01-18  9:28     ` Ferruh Yigit
2021-01-15  2:42 ` [dpdk-dev] [dpdk-dev v3 0/2] add new UDP tunnel port for ecpri Jeff Guo
2021-01-15  2:42   ` [dpdk-dev] [dpdk-dev v3 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15  2:42   ` [dpdk-dev] [dpdk-dev v3 2/2] app/testpmd: add new UDP tunnel port " Jeff Guo
2021-01-15  4:35 ` [dpdk-dev] [dpdk-dev v4 0/2] add new UDP tunnel port configure for eCPRI Jeff Guo
2021-01-15  4:35   ` [dpdk-dev] [dpdk-dev v4 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15  4:35   ` [dpdk-dev] [dpdk-dev v4 2/2] app/testpmd: add new UDP tunnel port " Jeff Guo
2021-01-15  5:15 ` [dpdk-dev] [dpdk-dev v5 0/2] add new UDP tunnel port configure " Jeff Guo
2021-01-15  5:15   ` [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15 12:23     ` Ferruh Yigit
2021-01-18  2:40       ` Guo, Jia
2021-01-15  5:15   ` [dpdk-dev] [dpdk-dev v5 2/2] app/testpmd: add new UDP tunnel port " Jeff Guo
2021-01-15 12:24     ` Ferruh Yigit
2021-01-15 12:28   ` [dpdk-dev] [dpdk-dev v5 0/2] add new UDP tunnel port configure " Ferruh Yigit
2021-01-19  3:59 ` [dpdk-dev] [dpdk-dev v4] net/ice: enable eCPRI tunnel port configure in dcf Jeff Guo
2021-01-19  4:15 ` Jeff Guo
2021-01-19  4:19 ` [dpdk-dev] [dpdk-dev v5] " Jeff Guo
2021-01-20 10:14   ` Zhang, Qi Z
2021-01-20 10:19     ` Thomas Monjalon
2021-01-20 10:23       ` Zhang, Qi Z
2021-01-20 10:30         ` Thomas Monjalon
2021-01-20 10:36           ` Zhang, Qi Z
2021-01-20 10:39             ` Thomas Monjalon

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=7ef7738be8304c42a69edc0b23e33a79@intel.com \
    --to=qi.z.zhang@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bingz@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=getelson@nvidia.com \
    --cc=haiyue.wang@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jia.guo@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=orika@nvidia.com \
    --cc=qiming.yang@intel.com \
    --cc=thomas@monjalon.net \
    /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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git