From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0084.outbound.protection.outlook.com [104.47.41.84]) by dpdk.org (Postfix) with ESMTP id 7CC9F2BA4 for ; Tue, 27 Sep 2016 13:35:49 +0200 (CEST) Received: from BN6PR03CA0055.namprd03.prod.outlook.com (10.173.137.17) by CY1PR0301MB0713.namprd03.prod.outlook.com (10.160.159.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Tue, 27 Sep 2016 11:35:48 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::180) by BN6PR03CA0055.outlook.office365.com (2603:10b6:404:4c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5 via Frontend Transport; Tue, 27 Sep 2016 11:35:47 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=nxp.com; linux.intel.com; dkim=none (message not signed) header.d=none;linux.intel.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.629.5 via Frontend Transport; Tue, 27 Sep 2016 11:35:47 +0000 Received: from [127.0.0.1] (B32944-11.ap.freescale.net [10.232.14.25]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id u8RBZfcm003667; Tue, 27 Sep 2016 04:35:45 -0700 To: Yuanhan Liu References: <1473072871-16108-1-git-send-email-pankaj.chauhan@nxp.com> <1473072871-16108-2-git-send-email-pankaj.chauhan@nxp.com> <84848c11-fc26-015f-b7f8-a27d0558ef0b@nxp.com> <20160919144303.GL23158@yliu-dev.sh.intel.com> <9807e34b-6553-7a10-516b-2c59ad5c667d@nxp.com> <20160926035607.GJ23158@yliu-dev.sh.intel.com> CC: "Tan, Jianfeng" , , , From: Pankaj Chauhan Message-ID: <2d3dbd38-7dba-3af4-ab0e-52bc48f861d6@nxp.com> Date: Tue, 27 Sep 2016 17:05:41 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160926035607.GJ23158@yliu-dev.sh.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131194497477092989; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.158.2; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(1110001)(1109001)(3190300001)(339900001)(24454002)(76104003)(189002)(377454003)(199003)(120886001)(65956001)(77096005)(65806001)(50986999)(23746002)(230700001)(47776003)(54356999)(76176999)(105606002)(4326007)(106466001)(104016004)(36756003)(97736004)(561944003)(83506001)(4001350100001)(33646002)(31686004)(626004)(19580395003)(8676002)(87936001)(586003)(93886004)(7246003)(7126002)(85426001)(189998001)(2906002)(5660300001)(8936002)(65826007)(356003)(110136003)(7846002)(86362001)(8666005)(69596002)(6916009)(81156014)(68736007)(50466002)(92566002)(305945005)(2950100002)(81166006)(31696002)(11100500001)(64126003)(41533002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0301MB0713; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD048; 1:RDMd7IbXRVNepHA4f1iCpLngX+VqmnxPwHe+V9P1u4vvbpRgYoPuD0wv1VxW+/CEpkaQBfB6mtkfNVLd8o7x1oqDs4LpEhmaQta9/tsiHJsMDieDmvXlpC66URzV6ro6Qn0UsEZoNMcUrC+qupVZ0Cui3ZAUTLiEegXJWDJkHNMJ9xYtPwjeCQvao/rOKoCGYACNrS6pJNis2e/TXX8SVm15Nri5mca04DyWYI8+tiNai7gJdjB7d1LEOLckH3YPsMLijHsBFuiLFkrFYjxBedGDCuVpogcrwZ/CIrcv4VdQJyGjkAl8W/50NzN8PWI1v0iqfXJ0sxB01mnpHWsaYWbK+sz862NldX0bo8e8OU5ESvWa9R3o3kpx4+Zb/9OFs0F9ICsee4ZXjYxFfGuiXRWnmx/xVBRyNDUu5B42a7dmGEmFjuWfxV5hpR4jHfu7Qw633hKplH2iSdx5nfsxzOuq4vvnQ1aHo9J4PbkR0viJrGXN/Ol2x4hU61UT/O5LHMnMojtDXlPOQjMVBtT0UVeQjB8WoFVOJbuWnX7P3qf1EoVWC5LoCl0+JPBBtXhdr6LOP2WlNnkXsx+5S8YS7v6dqbMsI1/pi8Yt/wZajJhv511MypHVY8ZxHi/VqG2khM3TlwgL7BBpzuq+kZFkVA== X-MS-Office365-Filtering-Correlation-Id: 8566ab31-fb7b-495d-a67d-08d3e6ca6d12 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0713; 2:8qQDBnAFGLywwzXed4Tor2hQMtefUFZ+c7KdFLBlBEKP3F/qaOR6PQSqBB3sRjQbPhLIc0QKSRNpK4RFS3OCzXD0PxbtUy2u9HqAmoSiYJRetH+PUb46++Mbtr5oXKhk0yd+71BI3jrDf6tB3Hw8kZCRq+RS1wC+cxH1s6gKbDVFT97zbn7Ps86vj3wZ1a8b; 3:5URbdSRSHwqwdbwZ3spYEJiiiKmzXi9rsape1/baVuyvIXXGfl9hjN29NcCkqQqqX3geFdXOscw61tlvBzxzLwtf0i0npw9YOIEweMEgJdrY+2vAB3zthMvg5+JivaVDfsPjrsKdDBcM6sqU+XOZXggoaPXZmS0OzSBkJhm7CcH80npDOxqRJVeXgxvcbxjts3KagGEXVXk4uiBd99mH3KgKeZtipY3U0RkCxnBnT78=; 25:1nAT7ImjP5oVCekEbyYNEmNOms9eNqoR+Be7n6tzAfG8hXKePWkL1LUm+9lcY9tC3Qb02VnWBe3X3ldZc/pokHzjs83s0/RN2ujt6gAcXZlBMr48qXJlYNsuXfH0NYWsWFqKB5BTOqN6Bin+MgYWJ+sqhgdz5GQR0zOo+t/cVowbxzo1FS4J5W+CKEyAx4lFaHXu/Nr0GX6zsoUj8eV9vch0NtIbmrnqbNv0X9Xyc/kEAW/IKF/8zcLsN4hJwhcS+lm0UBzMwgR9QjNg8yrunhknB/z43MIh2qHq0lfVHSX0dmIIYgh2C5iNWahfNSnWeMTVqUDqxKWs014LRioYcc5oV6LjkLWPADhmElgS4nEOggAcWpZVB/rdCZhn5Dc0LIRKZwTXEcHbVH2L/II/0BQoScM5QzWVaBs1BSgUHF0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0713; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0713; 31:X502NJ8NeVQLfAPIhOzBE07Q9e3O1SycJFCx2n6LJrV7rCTHh1RXcac3nt/GUn+MQtjvATBrys4l6Day/GbcYPVsdowFH26/X7Za8fZ6kBU7CT+j0SV0MiCX4jdQygxWvx6FUdk5Ncbbc71ko4DpLuL63M+jNiSep5G0Wy0OOVXrvbEDMHpEvlVui0/QQ1FMJOSz14N4mjh/OC9EtwadsLlTm7kwZE2VQeho7pkzB2w=; 4:2SsOxJ24EG5k8/ou1j/85qOmdBL0nZh/OiaG7mE15FcxkQdazsCmip91E8La4/7Wz55jToESX28KMb4n397/CETpRad0yb3OgpoDKaxx/gCfqmSQ/ugbQrxng+0r8cdPcpnE1Uu4MdbGSy2H//Lvz+BJ6eP+ZGPyWUg5xgR5DXR8d11qdUOnQsbqeR4oK1uL9SIsq2J2QUF3lCG6Kaf3PvSpmp0mKIXAEZv01fpjoFoCGB0eU+re0PcA6kFIjYdcb/fntKVQUO7SLOC5geBdSjbx3vtPNsb1YWOxsWTox2yKmpPM02hX8GP2R3wZmuumR4VL5T3kzKFlIZwDJmBFi5Mogd4cg+JgN4RW7hKYV374zFRSmMoz+1b0J+75Lge9wQRUfLwAzMjJiV+ycwzTcbGwN360TUMBAqRmtK1iXtBy3EoXSZbx7TVpmw4sJuu3yx+o/iLYywJbVVYS8781VOcUjKPt5JrbV0U28i+EP8H1ZKvAfgYM2G3l9N9xRlyLScoUgLFkPXK4LDxp3fFVI3t8bg6lUukbLthXD5mlo8k= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13023025)(13015025)(13017025)(13018025)(13024025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0301MB0713; BCL:0; PCL:0; RULEID:(400006); SRVR:CY1PR0301MB0713; X-Forefront-PRVS: 007814487B X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0301MB0713; 23:KdHJQFlw+l3+p+dTldT79nyun7hy6CVmJpJ?= =?Windows-1252?Q?O8rr9k1NK/5Si/pEoGk34dQUOy0a32Fmh/1eWSxFBcQjus94ZlJyBe/h?= =?Windows-1252?Q?BDrcLpFaeIbZ5HGG4BmHWRLFHtSiFrqvGonTRq8mF8Q711eH8PyuBSqF?= =?Windows-1252?Q?y+ueiVR5aB1QtQN3Yr/wnGqd9T9r+UDOP0kLLDxre3RZoJ0v6NmEwlcQ?= =?Windows-1252?Q?MMSP5dXzjJwrbQMCzs7FNoxK5e6smfwWVRmVjnFmLESE1+EYN7y6VW/o?= =?Windows-1252?Q?D7wG4epTETMNGGPyehA2fF3JOBGCprxzqy/817RtJ3yRchqdMylPI+HS?= =?Windows-1252?Q?w2yBPEZUwhYQg75lftIyzu1WpZfRQbavp2kJhXclBo3EztqjLtP6ouAD?= =?Windows-1252?Q?u0ANnNhF0TZMMg/KFLXIy7BvcBEjhLLXOaNS7Lu7axTT5IuPCAQSAd9y?= =?Windows-1252?Q?v+udNXR/ucS+KvzreSJJqRziQNLhAaVH9XvvXiqVpDjWVXgqCE/ScYoT?= =?Windows-1252?Q?6O2rJtKDSrsW9BIjH2JYdK3wSDblW7SDu0XJP0ZoueNu4HUf8KRkYwb7?= =?Windows-1252?Q?eHUWr0AT7+HNIx3P3AWjoEaS85K+rp7BPkI+SgBQv0I6A7LKvsZ07ieo?= =?Windows-1252?Q?0uAc4ANc9Dc/aBqRQ45oGphCKuqyYy39VVoWTRaCjZcdP/EWwtbh2n2r?= =?Windows-1252?Q?dGCJKmWrnprjL4gAxdqqpNRVuw7pWPLi0kAjavEcVD6TD9QRbn6rTBAH?= =?Windows-1252?Q?HwulMt5NyWeFWyAX03NMlfI4v8LtZI3tH1fmMsrkOuBi30/oGDNzGiDj?= =?Windows-1252?Q?RY8F7RHUCjJ/3tKc1HwVqkd+2BqWXp9EsAfABAdHt8PX9TO85m7yOSwF?= =?Windows-1252?Q?si32Uk3vEuDsTjD7GEaLv+qjc3m+yfx2XuOGb1iv/bHp5d/n9KLsgdT8?= =?Windows-1252?Q?gOuNNm1gnSeigsCJI28/nk/3I56Oq9sxUgHUiSVyQa/x1csdmaVfRUaC?= =?Windows-1252?Q?CR1pZcXEAbW2KHum4mrQUBSO1taocjwWGyO1iCkksZPHGQpLSqTyPSBe?= =?Windows-1252?Q?FfdVOFbrPnf0gIjeFGOwlC6MuzKdhytoxYzfMySPAvrV4jjsutiTvRwv?= =?Windows-1252?Q?rBBPcqXOz80kut0WeTId00G3M4JVrVjomzaEZDieW8DT1AUYP4ttukd2?= =?Windows-1252?Q?fMqIJt7C3RdP2O9Ybqo+ZrC3dpg1TxFotYaxl6BfQohkSVr6syPurwws?= =?Windows-1252?Q?DCwJRDE9WN340KKXycAHDgYET5GABBotIuAYUBKDqhPYaZv4EVKr0fyC?= =?Windows-1252?Q?Nps7sn7rlYN61P8+wHmJYd+i8/ejSKPCDJSfWXhFDuBcLvs37eq15Gra?= =?Windows-1252?Q?JKaIwwYh7BfYlMAOPCfj1xiH6eTW9NyqIGo61TC7KU6eo9OguzxmxD4f?= =?Windows-1252?Q?E52+q8Zq9Owvs34sds0TmAkF1bHOCaNV0dUpyYlx3ki6t7+nyMVKV2rw?= =?Windows-1252?Q?NtPwlHzY5o/V4zfxs8hnfbq+Y+WhF5o5sB1+JVFPs7JqiWUreLXvUpFJ?= =?Windows-1252?Q?gE33MDS2bjummZDvV/Zfp/8uBcugpBX3El9/JDot8vnCqY5OToDlRL8X?= =?Windows-1252?Q?N9mjHnMs+yBDkveedBwgNOuy6DIKqZKevO/lEFE1D4Cf4?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0713; 6:xb2KL96USwhbnxB10wTApeviTQHPhUzYHP8WXh6A3gQpxJJ5uR3DOddxwEMBXDVp4qy8WJrtjwDWd8z+nYbeJ4qJZ3OzWmahduyGF5zHeQ+Llmylmwh3SjmMWBJwTYkm6pcXl9nSAWJ+Dz59Ov7itdIgPRZ9Eja7QW29NwXQYYddgUDvH1pEdYFlbEP+FvtwJAL/vIDzjOy4gJDQqI9dkmhtvHNZJ546GttctozxM660lzVn17xiYIWfBLlo4Atfi4M8mC/PmJx6ecQUk83aO8xkeraOlNz0dVVGSib8Uds=; 5:pLS8GElaTyDIIDIOASjtjkcMz2GSzdbS6lsDYDjJdKK72PEb3sHDLRRxy7IZin1GV5t0MznRGRbSADKk8yQBnhTSCUO7XNEC9vspfBADvvtvChznxwfj1soBEPi3VmDkFfI80tpHgzGPEo6Bm3iGASW42JuBo6YIyaHax0ul1hU=; 24:LoLDHdbJjlcNw+Atg2GmH+J0O4VwLMusn4Y7tS002sCMEqhmTl9nEz1IfnvCm0hF0Xj6TwGF7GJjiFFRfAVfEWp2a00iuXzCa8jbB3RpbJI=; 7:Q4syNm1dECRah7fn0Hpn+OX4PdY5Odj5eDKen4SDlxRTjlJKPMhA8TMq0g31hYh+zcYNwoT9i9R/nctWVi0STHCcUvgD02XP+zGHPnAoVc/bCiD86bFWUU6gTJd4nDYCFQnUns8QX4k7MTxWdww/C+3Dj1pAG4sRbbM/vBfI+D/yt6uRD6Fk0x29EjVXVfNcrypU1nQS/WkVoqI3hlc6k1xNGqtXWaTYD7bF93Fcx70yUJLmonIrnyuBnxzIaxWpzOTh5e5epXiCRKqSZxJ0oWzDQu1WhYUWI2ZiEIgSStfGd955AOFK21n6tF8c8gUz SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2016 11:35:47.5689 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0713 Subject: Re: [dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework 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: Tue, 27 Sep 2016 11:35:50 -0000 On 9/26/2016 9:26 AM, Yuanhan Liu wrote: > On Tue, Sep 20, 2016 at 02:28:17PM +0530, Pankaj Chauhan wrote: >> On 9/19/2016 8:13 PM, Yuanhan Liu wrote: >>> Firstly, sorry for being late on this discussion: I just got a chance >>> to follow what you guys were talking about. >>> >>> On Tue, Sep 13, 2016 at 02:51:31PM +0800, Tan, Jianfeng wrote: >>>>> (2) we'd better not differentiate phys device and virtual >>> >>> Agreed. >>> >>>>>> device in generic framework (it's just an attribute of vswitch_port. >>>>>> >>>>>> What do you think? >>>>> >>>>> I agree with your thought that given the current API in this patchset we >>>>> should aim for making switch_worker agnostic of the port type. Ideally it >>>>> should look something like this: >>>>> >>>>> switch_worker() { >>>>> >>>>> rx_port mask = VSWITCH_PTYPE_PHYS | VSWITCH_PTYPE_PHYS; >>>>> >>>>> rx_port = vs_sched_rx_port(vswit_dev_g, rx_port_mask, core_id) >>>>> rx_q = rx_port->get_rxq(vs_port, vdev, code_id); >>>>> rx_port->do_rx(rx_port, rxq, NULL, pktss, MAX_PKT_BURST); >>>> >>>> Can we hide queues inside struct vswitch_port? I mean: >>>> For VMDQ switch, treat (port_id, queue_id) as a vswitch_port, so far you've >>>> already stored "struct vhost_dev *" into vswitch_port.priv when it's a >>>> virtual port, how about store queue_id into vswitch_port.priv when it's a >>>> physical port. >>> >>> Well, note that vhost-user also supports multiple queue; it's just >>> haven't been enabled yet. So, storing "vdev" for virtio port and >>> "queue_id" for phys port doesn't make too much sense. >>> >>>> For arp_learning switch, make (port_id, all_enabled_queues) as a >>>> vswitch_port. >>>> Summarize above two: we treat (port_id, all_enabled_queues[]) as a >>>> vswitch_port. >>>> >>>> How about it? >>> >>> Sorry, I don't quite like the idea. It's weird to use "vswitch_port + queue_id" >>> combination to represent a port. A vswitch_port should be just a port: let's >>> keep the logic that simple. >>> >> >> We wanted to take that approach to make vhost/main.c agnostic port type and >> have common code for rx/tx processing. The current version of patchset (v2) >> takes care of multiqueue, as it calls vs_port->get_txq/get_rxq to get the >> queue on which rx/tx has to be performed. This way the underlying switch can >> decide the queue based on core_id and vs_port. >> >> But in the v2 patchset we still bind vhost_dev to the cores, and pass it to >> vs_port->get_rxq() to get the rx_queue corresponding to vhost_dev. Jianfeng >> had suggested to remove vhost_dev to core binding, and bind vs_port to the >> cores. Creating one vswitch_port for a physical port + queue_id was a step >> in that direction, thus creating very generic code in vhost/main.c. >> >> YLiu/Jianfeng, >> >> Please suggest what approach we should take here? Should we keep the logic >> of binding vhost_dev to core (as in V2 patchset), thus leaving some >> intelligence about vhost_dev in vhost/main.c. >> >> Or What other options do you suggest if we want to achieve port type >> agnostic vhost/main.c > > Hi Pankaj, > > Again, apologize for late response: you see I was busy ;) Besides, I > need some time to think about it. > Hi YLiu, No issues with delayed response :) > Generally, I think your ideal proposal looks good to me (well, I don't > see the need of port mask): The idea of port mask was to give ability to the caller to choose which type of port to do rx from, Physical port or vhost port. > > switch_worker() { > rx_port = vs_sched_rx_port(vswit_dev_g, core_id) > rx_q = rx_port->get_rxq(vs_port, vdev, code_id); > rx_port->do_rx(rx_port, rxq, NULL, pktss, MAX_PKT_BURST); > > vs_lookup_n_fwd(rx_port, pkts, rx_count, rxq); > } > > The issue is, as you stated, VMDq it's bit tricky to handle. How about > the following proposal then? > > We don't have to register the nic queues while VMDq is used, since a > phys queue is bond to a virtio queue in this mode. That means only > virtio queues will be scheduled. > > The virtio do_rx might look like below then: > > vmdq_rx() { > rte_eth_rx_burst(port, queue_bond_to_this_virtio_queue, ...); > rte_vhost_enqueue_burst(...) if any; > > rte_vhost_dequeue_burst(...); > } > Okay so in that case, we won't do any rte_eth_rx_burst() when physical_port->do_rx is called, Correct?. If yes then in vmdq.c we'll overwrite vs_port->do_rx of physical port with a vmdq_do_rx_phys() which does nothing. Or we can even have an option that vmdq.c doesn't return the physical port when vs_sched_rx_port() is called, i think this later option is better to save some CPU cycles. I think it is possible but i would prefer to overwrite vs_port->do_rx() for vmdq (in vmdq.c) with the implementation that you suggested. The framework provides this option, i.e the switch implementation can overwrite the vs_port->do_rx/do_tx if required to handle any special cases for example the case of vmdq <> vdev boding. Thanks, Pankaj > --yliu >