Re: [dpdk-dev] olflags in SRIOV VF environment

[Vladimir Medvedkin <medvedkinv@gmail.com>]

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@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.
>
> ===============================================================================
>