Re: [dpdk-dev] [PATCH] ethdev: refine API description

-----Original Message-----
From: Thomas Monjalon <redacted>
Sent: Monday, January 18, 2021 5:50 PM
To: Zhang, Qi Z <redacted>
Cc: dev@dpdk.org; Yigit, Ferruh <redacted>; orika@nvidia.com;
getelson@nvidia.com; andrew.rybchenko@oktetlabs.ru;
ajit.khaparde@broadcom.com; jerinj@marvell.com
Subject: Re: [dpdk-dev] [PATCH] ethdev: refine API description

18/01/2021 05:01, Zhang, Qi Z:

quoted

From: Thomas Monjalon <redacted>

quoted

12/01/2021 12:47, Qi Zhang:

quoted

+ * This API is for the first case and typically it will only be
+ implemented
+ * on a PF driver or a VF driver which have privilege right to
+ configure for

What is a privileged VF exactly?

Yes, looks like "a privileged VF" is not generic enough here, actually
it should be a driver that implement DPDK ethdev API and able to perform

device/port level configure, for example use rte_flow to steer traffic to specific
VF, configure UDP tunnel port .... it is something like a "host driver"

quoted

It could be a pure user pace DPDK PF driver, or a vdev / SR-IOV driver back

ended by a kernel driver but be granted to have privilege to access more device
resource through some sw/hw channel.

How such device is granted privilege?

There is no unified way currently as I know, but typically it should be configured from the host by an administrator through tools like ip / devlink ...

quoted

quoted

quoted

+ * other VFs. For the second case, a tunnel configure could be
+ embedded in a
+ * rte_flow rule.

I suggest we make the explanation more API-oriented.

First thing to explain: this API will have effect on rte_flow rules only, am I

right?

quoted

I think it should not only impact the rte_flow, but also may impact
the packet type that extract from Rx Descriptor to mbuf on some
devices Because without this configure, the parser is not able to
recognize the specific tunnel type

Oh right.
This impact on mbuf classification should be part of the doxygen explanation.

quoted

quoted

What does it mean for a flow rule matching on a specific tunnel?
Let's take an example config:
	rte_eth_dev_udp_tunnel_port_add [UDP X] [tunnel T]
	rte_flow_create [tunnel T] [action A]
	rte_flow_create [UDP Y] [tunnel T] [action B] Then action for these

Some driver may not allow to specific a tunnel port in rte_flow as

rte_eth_dev_udp_tunnel_port_add is prefer API to handle this.

Every rte_flow items and actions have limitations in drivers, that's OK.

quoted

quoted

packets:
	1/ [UDP X] - no tunnel header
-> A (rte_eth_udp_tunnel skips the tunnel header check) or none,
-> tunnel header is checked according to rte_flow?

If a packet only have udp tunnel port but don't have tunnel header, so the

packet will still not be recognized as a an tunnel packet by the parser, the pattern
is not matched and action A should not be executed.

OK I like it. Please make this behaviour clear in the doxygen.

quoted

quoted

	2/ [UDP Y] - no tunnel header
-> none (flow rule requires a tunnel header)

Yes, expected result

quoted

	3/ [UDP X] [tunnel T]
-> A

Yes, expected result

quoted

	4/ [UDP Y] [tunnel T]
-> B

Yes, expected result, if the rule #2 is allowed to create

Yes of course, if the rule cannot be created, the driver will reject it with an
appropriate error code and a log mentioning the limitation.

quoted

quoted

	5/ [UDP X] [tunnel U]
-> A (rte_eth_udp_tunnel skips the tunnel header check) or none,
-> tunnel header is checked according to rte_flow?

Should be none.

OK makes sense.

quoted

quoted

	6/ [UDP Y] [tunnel U]
-> none

Yes expected result.

quoted

Last question, how it plays with rte_flow_tunnel_match?
Should we replace rte_eth_udp_tunnel with rte_flow_tunnel_match?

My understanding is rte_flow_tunnel_match is just a help function, it help to

generate a set of rte_flow_items to feed a new rule creation, so looks like it is
not expected to have any interaction with hardware? So I didn't figure out how
can we use it to replace,  But maybe we can introduce something new like
rte_flow_tunnel_create as we already have a rte_flow_tunnel structure which
looks more generic than the existing API that only take udp port for tunnel
configure.

Yes we need to think about it for future more generic API.
Ori, any thoughts?