[dpdk-dev] olflags in SRIOV VF environment

[Prashant Upadhyaya]

Thanks Vladimir !
That seems to be the issue. Better to parse it by hand right now instead of depending on ol_flags.

Regards
-Prashant

From: Vladimir Medvedkin [mailto:medvedkinv at gmail.com]
Sent: Tuesday, November 12, 2013 7:54 PM
To: Prashant Upadhyaya
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] olflags in SRIOV VF environment

Hi Prashant,
May be it doesn't work due to Known Issues and Limitations (see Release Notes)
quote:

6.1 In packets provided by the PMD, some flags are missing
In packets provided by the PMD, some flags are missing. The application does not have access to information provided by the hardware (packet is broadcast, packet is multicast, packet is IPv4 and so on).

Regards,
Vladimir

2013/11/12 Prashant Upadhyaya <prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>>
Hi guys,

I am facing a peculiar issue with the usage of struct rte_mbuf-> ol_flags field in the rte_mbuf when I receive the packets with the rte_eth_rx_burst function.
I use the ol_flags field to identify whether is an IPv4 or IPv6 packet or not thus -

if ((pkts_burst->ol_flags & PKT_RX_IPV4_HDR) ||
                                                (pkts_burst->ol_flags & PKT_RX_IPV6_HDR))

[pkts_burst is my rte_mbuf pointer]

Now here are the observations -


1.       This works mighty fine when my app is working on the native machine

2.       This works good when I run this in a VM and use one VF over SRIOV from one NIC port

3.       This works good when I run this in two VM's and use one VF from 2 different NIC ports (one VF from each) and use these VF's in these 2 VM's (VF1 from NIC port1 in VM1 and VF2 from NIC port2 in VM2)

4.       However the ol_flags fails to classify the packets when I use 2 VM's and use 2 VF's from the 'same' NIC port and expose one each to the 2 VM's I have

There is no bug in my 'own' application, because when I stopped inspecting the ol_flags for classification of IPv4 and V6 packets and wrote a mini logic of my own by inspecting the ether type of the packets (the packets themselves come proper in all the cases, thankfully), my entire usecase passes (it is a rather significant usecase, so it can't be luck)

Any idea guys why it works and doesn't work ?

Regards
-Prashant





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================