> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Monday, January 18, 2021 5:50 PM
> To: Zhang, Qi Z <qi.z.zh...@intel.com>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yi...@intel.com>; or...@nvidia.com;
> getel...@nvidia.com; andrew.rybche...@oktetlabs.ru;
> ajit.khapa...@broadcom.com; jer...@marvell.com
> Subject: Re: [dpdk-dev] [PATCH] ethdev: refine API description
>
> 18/01/2021 05:01, Zhang, Qi Z:
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 12/01/2021 12:47, Qi Zhang:
> > > > + * 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"
> > 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 ...
>
>
> > > > + * 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?
> >
> > 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.
>
>
> > > 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.
>
> > > 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.
>
>
> > > 2/ [UDP Y] - no tunnel header
> > > -> none (flow rule requires a tunnel header)
> >
> > Yes, expected result
> >
> > > 3/ [UDP X] [tunnel T]
> > > -> A
> >
> > Yes, expected result
> >
> > > 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.
>
> > > 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.
>
> > > 6/ [UDP Y] [tunnel U]
> > > -> none
> >
> > Yes expected result.
> > >
> > > 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?
>
