DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] olflags in SRIOV VF environment
@ 2013-11-12 13:44 Prashant Upadhyaya
  2013-11-12 14:24 ` Vladimir Medvedkin
  0 siblings, 1 reply; 3+ messages in thread
From: Prashant Upadhyaya @ 2013-11-12 13:44 UTC (permalink / raw)
  To: dev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] olflags in SRIOV VF environment
  2013-11-12 13:44 [dpdk-dev] olflags in SRIOV VF environment Prashant Upadhyaya
@ 2013-11-12 14:24 ` Vladimir Medvedkin
  2013-11-13  5:41   ` Prashant Upadhyaya
  0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Medvedkin @ 2013-11-12 14:24 UTC (permalink / raw)
  To: Prashant Upadhyaya; +Cc: dev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] olflags in SRIOV VF environment
  2013-11-12 14:24 ` Vladimir Medvedkin
@ 2013-11-13  5:41   ` Prashant Upadhyaya
  0 siblings, 0 replies; 3+ messages in thread
From: Prashant Upadhyaya @ 2013-11-13  5:41 UTC (permalink / raw)
  To: Vladimir Medvedkin; +Cc: dev

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@gmail.com]
Sent: Tuesday, November 12, 2013 7:54 PM
To: Prashant Upadhyaya
Cc: dev@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@aricent.com<mailto: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.
===============================================================================





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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-11-13  5:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-12 13:44 [dpdk-dev] olflags in SRIOV VF environment Prashant Upadhyaya
2013-11-12 14:24 ` Vladimir Medvedkin
2013-11-13  5:41   ` Prashant Upadhyaya

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).