[dpdk-users] Why flow can not be created?

[Moti Haimovsky]

Mlnx5 Patches supporting rte-flow  Vlan push/pop actions were submitted today. 
Moti

> -----Original Message-----
> From: users <users-bounces at dpdk.org> On Behalf Of Adrien Mazarguil
> Sent: Tuesday, August 6, 2019 12:13 PM
> To: Hideyuki Yamashita <yamashita.hideyuki at ntt-tx.co.jp>
> Cc: Ye Xiaolong <xiaolong.ye at intel.com>; users at dpdk.org
> Subject: Re: [dpdk-users] Why flow can not be created?
> 
> On Fri, Aug 02, 2019 at 03:06:19PM +0900, Hideyuki Yamashita wrote:
> > Helllo Experts,
> 
> I think most of them are on vacation :)
> 
> > Q1. Are there any NICs which supports entag/detag VLAN?
> > I searched source DPDK source code with keyword "OF_POP_VLAN" or
> "OF_POP_VLAN"
> > and found some codes within mlx5_flow_tcf.c and cxgbe_flow.c.
> 
> Indeed only those two seem to implement that. However depending on
> what you're trying to achieve, there could be a workaround as many drivers
> provide support for VLAN entag/detag outside rte_flow.
> 
> For Rx, you can dedicate queues to perform VLAN stripping through
> rte_eth_dev_set_vlan_strip_on_queue(), and use rte_flow to redirect
> traffic of interest to these queues after matching specific VLANs and other
> properties for instance.
> 
> If you don't care about specific VLANs or queues, you can request VLAN
> stripping globally using ETH_VLAN_STRIP_OFFLOAD with
> rte_eth_dev_set_vlan_offload(), then rely on mbuf->ol_flags &
> PKT_RX_VLAN to retrieve it from mbuf->vlan_tci.
> 
> On the Tx side you simply have to request mbuf->ol_flags | PKT_TX_VLAN
> while doing Tx. As for Rx, make sure DEV_TX_OFFLOAD_VLAN_INSERT is
> among the Tx offloads requested during setup (rte_eth_conf-
> >txmode.offloads).
> 
> > Q2. Are there any plans in DPDK community to update document about NIC
> > to update support of rte_flow?
> > I have heard the situation about document form Adrien, and to be
> > honest I felt it is very hard to take try and error with testpmd for every NIC.
> 
> This was discussed in the past, however so far no action was taken.
> 
> I think we cannot summarize all supported combinations for each NIC while
> covering their specific quirks efficiently. For instance, two NICs may support a
> given pattern item, but not necessarily at the same position in the pattern.
> Likewise for pattern item fields, they may not support the same masks.
> 
> The most sensible approach is perhaps to provide a list of popular flow rules
> tagged with the NICs supporting them.
> 
> Anyway since it's not a huge priority at the moment, you should start a
> discussion on that topic on the dev at dpdk.org mailing list. Without noise,
> nothing will happen :) As usual contributions are always welcome!
> 
> --
> Adrien Mazarguil
> 6WIND