From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 858061B7B9 for ; Fri, 13 Apr 2018 05:18:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 20:18:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,444,1517904000"; d="scan'208";a="220054230" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga005.fm.intel.com with ESMTP; 12 Apr 2018 20:18:21 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 12 Apr 2018 20:18:21 -0700 Received: from bgsmsx105.gar.corp.intel.com (10.223.43.197) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 12 Apr 2018 20:18:21 -0700 Received: from bgsmsx101.gar.corp.intel.com ([169.254.1.52]) by BGSMSX105.gar.corp.intel.com ([169.254.3.206]) with mapi id 14.03.0319.002; Fri, 13 Apr 2018 08:48:18 +0530 From: "Varghese, Vipin" To: Ophir Munk , "dev@dpdk.org" , "pascal.mazon@6wind.com" , "Yigit, Ferruh" , Thomas Monjalon , Olga Shern , Shahaf Shuler Thread-Topic: [dpdk-dev] [PATCH 1/2] net/tap: add tun support Thread-Index: AQHTypsdhempI7P0FUC67o3nf5WGVaP8tx0AgAFX1FA= Date: Fri, 13 Apr 2018 03:18:17 +0000 Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D1C8BAB@BGSMSX101.gar.corp.intel.com> References: <1519625719-10443-1-git-send-email-vipin.varghese@intel.com> <1522705068-18198-1-git-send-email-vipin.varghese@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzM2MzgwODctN2VlYS00N2Q5LWJlZDctMGEzMjQyMDQxYjM0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJIdlhDWDdnWENBQmYxSktKdTFaWTZ4ZGUrOXVPRUVBMm9VQjNsVWRnN3lvNzdueERYM1ZSNXE3c2ZMS3lXQlYwIn0= dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.223.10.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] net/tap: add tun support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 03:18:25 -0000 Hi Ophir, Please find my answers inline to the queries. > -----Original Message----- > From: Ophir Munk [mailto:ophirmu@mellanox.com] > Sent: Thursday, April 12, 2018 5:19 PM > To: Varghese, Vipin ; dev@dpdk.org; > pascal.mazon@6wind.com; Yigit, Ferruh ; Thomas > Monjalon ; Olga Shern ; > Shahaf Shuler > Subject: RE: [dpdk-dev] [PATCH 1/2] net/tap: add tun support >=20 > Hi Vipin, > This patch (adding TUN to TAP) has been Acked and accepted in next-net > branch. > I have some questions regarding the implementation (please find below). >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vipin Varghese > > Sent: Tuesday, April 03, 2018 12:38 AM > > To: dev@dpdk.org; pascal.mazon@6wind.com; ferruh.yigit@intel.com > > Cc: Vipin Varghese > > Subject: [dpdk-dev] [PATCH 1/2] net/tap: add tun support > > > > The change adds functional TUN PMD logic to the existing TAP PMD. > > TUN PMD can be initialized with 'net_tunX' where 'X' represents unique = id. > > PMD supports argument interface, while MAC address and remote are not > > supported. > > >=20 > [...] >=20 > > > > + /* > > + * TUN and TAP are created with IFF_NO_PI disabled. > > + * For TUN PMD this mandatory as fields are used by > > + * Kernel tun.c to determine whether its IP or non IP > > + * packets. > > + * > > + * The logic fetches the first byte of data from mbuf. > > + * compares whether its v4 or v6. If none matches default > > + * value 0x00 is taken for protocol field. > > + */ > > + char *buff_data =3D rte_pktmbuf_mtod(seg, void *); > > + j =3D (*buff_data & 0xf0); > > + if (j & (0x40 | 0x60)) > > + pi.proto =3D (j =3D=3D 0x40) ? 0x0008 : 0xdd86; > > + >=20 > 1. Accessing the first byte here assumes it is the first IP header byte (= layer 3) > which is correct for TUN. > For TAP however the first byte belongs to Ethernet destination address > (layer 2). > Please explain how this logic will work for TAP. Based on linux code base '/driver/net/tap.c' and '/driver/net/tun.c' from 3= .13. to 4.16,=20 Please find my observation below 1. File: tun.c, function: tun_get_user, check for 'tun->flags & TUN_TYPE_MA= SK' is done and if non ip is taken counter 'rx_dropped' is updated. 2. File: tap.c, there are no checks for 'tap->flags' for IFF_NO_PI in rx da= ta path. Counter 'rx_dropped' is updated in 'tap_handle_frame'.=20 Please find my reasoning below 1. First approach was to have separate function for tap and tun TX and RX. = But this will introduce code duplication, hence reworked the code as above. 2. During my internal testing assigning dummy value for protocol field in T= AP packets, did not show a difference in behaviour. May be there are some s= pecific cases this failing.=20 If there difference in behaviour, can please share the same? >=20 > 2. If the first TUN byte contains 0x2X (which is neither IPv4 nor IPv6) i= t will > end up by setting ip.proto as 0xdd86. > Please explain how this logic will work for non-IP packets in TUN I see your point. You are correct about this. Thanks for pointing out, may = I send correction for this as """ - if (j & (0x40 | 0x60)) - pi.proto =3D (j =3D=3D 0x40) ? 0x0008 : 0xdd86; + pi.proto =3D (j =3D=3D 0x40) ? 0x0008 :=20 + (j =3D=3D 0x60) ? 0xdd86 : + 0x00; """