From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by dpdk.org (Postfix) with ESMTP id 16175156 for ; Wed, 13 Nov 2013 06:40:25 +0100 (CET) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id E2B8A36BB6; Wed, 13 Nov 2013 11:11:01 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id CC44736BB0; Wed, 13 Nov 2013 11:11:01 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Wed, 13 Nov 2013 11:11:01 +0530 From: Prashant Upadhyaya To: Vladimir Medvedkin Date: Wed, 13 Nov 2013 11:11:00 +0530 Thread-Topic: [dpdk-dev] olflags in SRIOV VF environment Thread-Index: Ac7fstmcWfpjIgX5S22ScmEY10HkfQAf/iag Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-TM-AS-MML: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] olflags in SRIOV VF environment X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:40:25 -0000 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 Not= es) 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 doe= s not have access to information provided by the hardware (packet is broadc= ast, packet is multicast, packet is IPv4 and so on). Regards, Vladimir 2013/11/12 Prashant Upadhyaya > Hi guys, I am facing a peculiar issue with the usage of struct rte_mbuf-> ol_flags f= ield in the rte_mbuf when I receive the packets with the rte_eth_rx_burst f= unction. I use the ol_flags field to identify whether is an IPv4 or IPv6 packet or n= ot 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 machin= e 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 log= ic of my own by inspecting the ether type of the packets (the packets thems= elves 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D