Hello Adrien, Thanks for your response. > On Fri, Aug 02, 2019 at 03:06:19PM +0900, Hideyuki Yamashita wrote: > > Helllo Experts, > > I think most of them are on vacation :) [Hideyuki] I agree. How about you?
> > 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). [Hideyuki] There are at least 3 alternatives for Entag/Detag VLAN tag in hardware. Alt1: rte_flow only (mlx5, cxgbe supports?) Alt2: rte_eth_dev_set_vlan_strip_on_queue() call combine with rte_flow (route specific traffic to specific quueue) this is applicable for RX only Alt3: rte_eth_dev_set_vlan_offload() Q1. Why there are multiple way to achieve same purpose? (Is it long story?) > > 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. [Hideyuki] Thanks for summerizing up the problem. So many combinations to be sorted even for one NIC. And it makes more difficult to sort out support status for all NICs, right? > The most sensible approach is perhaps to provide a list of popular flow > rules tagged with the NICs supporting them. Maybe it is a very good starting point. I agree that if it is difficult to sort out "everything", to limit number is the possible solution - limit the number of NICs or - limit the flow rules (typical flows) > Anyway since it's not a huge priority at the moment, you should start a > discussion on that topic on the [email protected] mailing list. Without noise, > nothing will happen :) As usual contributions are always welcome! OK. Thanks I will come back to dev-ml with "what we want from user perspective". Thanks for your guidance. BR, Hideyuki Yamashita NTT TechnoCross > -- > Adrien Mazarguil > 6WIND ------------------------------------------------ NTTテクノクロス株式会社 フューチャーネットワーク事業部 第一事業ユニット 山下 英之(email: [email protected]) 〒167-0043 東京都杉並区上荻1-2-1 荻窪インテグラルタワー13F TEL 03-5347-8026 FAX 03-3392-6803 ------------------------------------------------------
