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