From: Thomas Monjalon <thomas@monjalon.net>
To: "Jiawei(Jonny) Wang" <jiaweiw@nvidia.com>
Cc: Slava Ovsiienko <viacheslavo@nvidia.com>,
Ori Kam <orika@nvidia.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>,
Raslan Darawsheh <rasland@nvidia.com>,
Ivan Malov <ivan.malov@oktetlabs.ru>,
"jerinj@marvell.com" <jerinj@marvell.com>
Subject: Re: [RFC 1/5] ethdev: add port affinity match item
Date: Wed, 18 Jan 2023 17:26:53 +0100 [thread overview]
Message-ID: <6248682.NeCsiYhmir@thomas> (raw)
In-Reply-To: <PH0PR12MB54515D73882733469F705705C6C79@PH0PR12MB5451.namprd12.prod.outlook.com>
18/01/2023 15:41, Jiawei(Jonny) Wang:
> Hi,
>
> >
> > 21/12/2022 11:29, Jiawei Wang:
> > > + /**
> > > + * Matches on the physical port affinity of the received packet.
> > > + *
> > > + * See struct rte_flow_item_port_affinity.
> > > + */
> > > + RTE_FLOW_ITEM_TYPE_PORT_AFFINITY,
> > > };
> >
> > I'm not sure about the word "affinity".
> > I think you want to match on a physical port.
> > It could be a global physical port id or an index in the group of physical ports
> > connected to a single DPDK port.
> > In first case, the name of the item could be RTE_FLOW_ITEM_TYPE_PHY_PORT,
> > in the second case, the name could be
> > RTE_FLOW_ITEM_TYPE_MHPSDP_PHY_PORT,
> > "MHPSDP" meaning "Multiple Hardware Ports - Single DPDK Port".
> > We could replace "PHY" with "HW" as well.
> >
>
> Since DPDK only probe/attach the single port, seems first case does not meet this case.
> Here, 'affinity' stands for the packet association with actual physical port.
I think it is more than affinity because the packet is effectively
received from this port.
And the other concern is that this name does not give any clue
that we are talking about multiple ports merged in a single one.
> > Note that we cannot use the new item
> > RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
> > because we are in a case where multiple hardware ports are merged in a single
> > software represented port.
> >
> >
> > [...]
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this structure may change without prior notice
> > > + *
> > > + * RTE_FLOW_ITEM_TYPE_PORT_AFFINITY
> > > + *
> > > + * For the multiple hardware ports connect to a single DPDK port
> > > +(mhpsdp),
> > > + * use this item to match the hardware port affinity of the packets.
> > > + */
> > > +struct rte_flow_item_port_affinity {
> > > + uint8_t affinity; /**< port affinity value. */ };
> >
> > We need to define how the port numbering is done.
> > Is it driver-dependent?
> > Does it start at 0? etc...
>
> User can define any value they want; one use case is the packet could be received and
> sent to same port, then they can set the same 'affinity' value in flow and queue configuration.
No it does not work.
If ports are numbered 1 and 2, and user thinks it is 0 and 1,
the port 2 won't be matched at all.
> The flow behavior is driver dependent.
>
> Thanks.
next prev parent reply other threads:[~2023-01-18 16:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 10:29 [RFC 0/5] add new port affinity item and affinity in Tx queue API Jiawei Wang
2022-12-21 10:29 ` [RFC 1/5] ethdev: add port affinity match item Jiawei Wang
2023-01-11 16:41 ` Ori Kam
2023-01-18 11:07 ` Thomas Monjalon
2023-01-18 14:41 ` Jiawei(Jonny) Wang
2023-01-18 16:26 ` Thomas Monjalon [this message]
2023-01-24 14:00 ` Jiawei(Jonny) Wang
2022-12-21 10:29 ` [RFC 2/5] ethdev: introduce the affinity field in Tx queue API Jiawei Wang
2023-01-11 16:47 ` Ori Kam
2023-01-18 11:37 ` Thomas Monjalon
2023-01-18 14:44 ` Jiawei(Jonny) Wang
2023-01-18 16:31 ` Thomas Monjalon
2023-01-24 13:32 ` Jiawei(Jonny) Wang
2022-12-21 10:29 ` [RFC 3/5] drivers: add lag Rx port affinity in PRM Jiawei Wang
2022-12-21 10:29 ` [RFC 4/5] net/mlx5: add port affinity item support Jiawei Wang
2022-12-21 10:29 ` [RFC 5/5] drivers: enhance the Tx queue affinity Jiawei Wang
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=6248682.NeCsiYhmir@thomas \
--to=thomas@monjalon.net \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=ivan.malov@oktetlabs.ru \
--cc=jerinj@marvell.com \
--cc=jiaweiw@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=viacheslavo@nvidia.com \
--cc=yuying.zhang@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
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).