* [dpdk-dev] Byte order of vlan_tci of rte_mbuf is different on different source @ 2016-04-25 2:35 zhang.xinghua1 2016-04-29 7:29 ` Olivier Matz 0 siblings, 1 reply; 3+ messages in thread From: zhang.xinghua1 @ 2016-04-25 2:35 UTC (permalink / raw) To: dev When using I350 working on SR-IOV mode, we got confused that byte order of vlan_tci in the VF received packet descriptor is different when the packet source is different. 1) Packets from VF to VF, the byte order is big-endian. (e.g. 0xF00) 2) Packets from PC to VF, the byte order is little-endian. (e.g. 0xF) Below is the testing net-work: VM0 VM1 PC VF0 VF1 | | | | +------+------+ | | | PF | hypervisor | SR-IOV NIC | | | | VLAN 15 | +---------switch-------+ We make a breakpoint at the following line of eth_igb_recv_pkts, the vlan_tci we observed that everytime. uint16_t eth_igb_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts) /* Only valid if PKT_RX_VLAN_PKT set in pkt_flags */ rxm->vlan_tci = rte_le_to_cpu_16(rxd.wb.upper.vlan); Thanks. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] Byte order of vlan_tci of rte_mbuf is different on different source 2016-04-25 2:35 [dpdk-dev] Byte order of vlan_tci of rte_mbuf is different on different source zhang.xinghua1 @ 2016-04-29 7:29 ` Olivier Matz 2017-08-24 14:16 ` Roger B Melton 0 siblings, 1 reply; 3+ messages in thread From: Olivier Matz @ 2016-04-29 7:29 UTC (permalink / raw) To: zhang.xinghua1, dev Hi, On 04/25/2016 04:35 AM, zhang.xinghua1@zte.com.cn wrote: > When using I350 working on SR-IOV mode, we got confused that byte order > of vlan_tci in the VF received packet descriptor is different when the > packet source is different. > > 1) Packets from VF to VF, the byte order is big-endian. (e.g. 0xF00) > 2) Packets from PC to VF, the byte order is little-endian. (e.g. 0xF) > > Below is the testing net-work: > VM0 VM1 PC > VF0 VF1 | > | | | > +------+------+ | > | | > PF | > hypervisor | > SR-IOV NIC | > | | > | VLAN 15 | > +---------switch-------+ > > > We make a breakpoint at the following line of eth_igb_recv_pkts, the > vlan_tci > we observed that everytime. > > uint16_t > eth_igb_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, > uint16_t nb_pkts) > > /* Only valid if PKT_RX_VLAN_PKT set in pkt_flags */ > rxm->vlan_tci = rte_le_to_cpu_16(rxd.wb.upper.vlan); In rte_mbuf.h, it is specified that these values (vlan_tci and vlan_tci_outer) must be stored in CPU order. It's probably a driver or hardware issue. Note that in linux there is something that looks similar to your issue: http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/igb/igb_main.c#L1278 /* On i350, i354, i210, and i211, loopback VLAN packets * have the tag byte-swapped. */ if (adapter->hw.mac.type >= e1000_i350) set_bit(IGB_RING_FLAG_RX_LB_VLAN_BSWAP, &ring->flags); I think you could check if the same thing is done in the dpdk driver. > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > This notice should be removed in public emails. Regards, Olivier ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] Byte order of vlan_tci of rte_mbuf is different on different source 2016-04-29 7:29 ` Olivier Matz @ 2017-08-24 14:16 ` Roger B Melton 0 siblings, 0 replies; 3+ messages in thread From: Roger B Melton @ 2017-08-24 14:16 UTC (permalink / raw) To: Olivier Matz, zhang.xinghua1, dev Hi folks, Resurrecting this old thread. I ran across this issue recently in DPDK 17.05, and it's also present in17.08. It appears no fix was committed. I'm working on a solution, but if anyone has a fix in flight please let me know. Regards, Roger On 4/29/16 3:29 AM, Olivier Matz wrote: > Hi, > > On 04/25/2016 04:35 AM, zhang.xinghua1@zte.com.cn wrote: >> When using I350 working on SR-IOV mode, we got confused that byte order >> of vlan_tci in the VF received packet descriptor is different when the >> packet source is different. >> >> 1) Packets from VF to VF, the byte order is big-endian. (e.g. 0xF00) >> 2) Packets from PC to VF, the byte order is little-endian. (e.g. 0xF) >> >> Below is the testing net-work: >> VM0 VM1 PC >> VF0 VF1 | >> | | | >> +------+------+ | >> | | >> PF | >> hypervisor | >> SR-IOV NIC | >> | | >> | VLAN 15 | >> +---------switch-------+ >> >> >> We make a breakpoint at the following line of eth_igb_recv_pkts, the >> vlan_tci >> we observed that everytime. >> >> uint16_t >> eth_igb_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, >> uint16_t nb_pkts) >> >> /* Only valid if PKT_RX_VLAN_PKT set in pkt_flags */ >> rxm->vlan_tci = rte_le_to_cpu_16(rxd.wb.upper.vlan); > In rte_mbuf.h, it is specified that these values (vlan_tci and > vlan_tci_outer) must be stored in CPU order. > > It's probably a driver or hardware issue. Note that in linux there is > something that looks similar to your issue: > > http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/igb/igb_main.c#L1278 > > /* On i350, i354, i210, and i211, loopback VLAN packets > * have the tag byte-swapped. > */ > if (adapter->hw.mac.type >= e1000_i350) > set_bit(IGB_RING_FLAG_RX_LB_VLAN_BSWAP, &ring->flags); > > I think you could check if the same thing is done in the > dpdk driver. > > >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. >> > This notice should be removed in public emails. > > Regards, > Olivier > . > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-08-24 14:16 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-25 2:35 [dpdk-dev] Byte order of vlan_tci of rte_mbuf is different on different source zhang.xinghua1 2016-04-29 7:29 ` Olivier Matz 2017-08-24 14:16 ` Roger B Melton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).