From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Vivek Sharma <vivek.sharma@caviumnetworks.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] RTE-FLOW: PF vs PHY_PORT
Date: Mon, 27 Aug 2018 15:45:50 +0200 [thread overview]
Message-ID: <20180827134550.GD3695@6wind.com> (raw)
In-Reply-To: <ae99760b-6920-9d3d-927d-d72747457b75@caviumnetworks.com>
Hi Vivek,
On Wed, Aug 22, 2018 at 05:16:52PM +0530, Vivek Sharma wrote:
> Hi Devs,
>
> I am trying to enable RTE-FLOW support on one of our platforms & having hard time in figuring out PF vs PHY_PORT differences and DPDK rationale for introducing these two distinct identities.
>
> Rte-Flow distinguishes between RTE_FLOW_ITEM_TYPE_PF & RTE_FLOW_ITEM_TYPE_PHY_PORT and
>
> RTE_FLOW_ACTION_TYPE_PF & RTE_FLOW_ACTION_TYPE_PHY_PORT.
>
>
> I am finding it difficult to justify the presence of both these types, when functionality & implementation wise, these look quite similar. I would really appreciate if you could illustrate the differences between above item & action types by taking some hardware/platform as reference.
Some devices, typically those with a single PCI bus address shared for all
ports (e.g. Mellanox ConnectX-3) expose all their physical ports to each
PF/VF instance [1], not the other way around. With these, PHY_PORT item and
action give the ability to select a nondefault physical port in a flow rule.
PHY_PORT cannot be specified on most devices with PF/VF dedicated to
physical ports, although their drivers should at least recognize 0 as a
supported index and ignore it.
Since devices can expose any number of PF/VF instances and physical ports,
this gives applications the ability to use both as matching criteria and/or
action target.
A higher level alternative to PHY_PORT and PF/VF items/actions is PORT_ID to
match/target DPDK port IDs, which users may find more convenient. One
drawback is that it only works with devices instantiated within DPDK.
PF/VF and PHY_PORT should be reserved for corner cases where PORT_ID cannot
be used. My advice is to implement PORT_ID and not bother with the others
since port IDs are what applications are familiar with.
[1] Although with CX3, individual ports can be disabled per VF, they remain
"seen" by each instance.
--
Adrien Mazarguil
6WIND
prev parent reply other threads:[~2018-08-27 13:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-22 11:46 Vivek Sharma
2018-08-27 13:11 ` Vivek Sharma
2018-08-27 13:45 ` Adrien Mazarguil [this message]
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=20180827134550.GD3695@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=vivek.sharma@caviumnetworks.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).