DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Guo, Jia" <jia.guo@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: dev@dpdk.org, 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: Fri, 15 Jan 2021 16:15:15 +0100
Message-ID: <1865276.fGLmMQUtVj@thomas> (raw)
In-Reply-To: <7ef7738be8304c42a69edc0b23e33a79@intel.com>

12/01/2021 03:14, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 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.

Thank you for trying to improve the doc.


> > > 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?

Sorry I don't know exactly what are the limitations.
From DPDK point of view, when a flow rule cannot be created,
it returns an error and the app must handle.
Yes the app must handle limitations because there is no magic
with hardware offloads: hardware are all more or less limited,
that's a sad truth of our finite world ;)



  reply	other threads:[~2021-01-15 15:15 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
2021-01-15 15:15                                           ` Thomas Monjalon [this message]
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=1865276.fGLmMQUtVj@thomas \
    --to=thomas@monjalon.net \
    --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=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.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

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