From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0077.outbound.protection.outlook.com [104.47.40.77]) by dpdk.org (Postfix) with ESMTP id 1AE765689 for ; Thu, 15 Sep 2016 11:01:07 +0200 (CEST) Received: from DM5PR03CA0002.namprd03.prod.outlook.com (10.175.104.12) by DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.8; Thu, 15 Sep 2016 09:01:05 +0000 Received: from BN1AFFO11FD033.protection.gbl (2a01:111:f400:7c10::158) by DM5PR03CA0002.outlook.office365.com (2603:10b6:3:118::12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10 via Frontend Transport; Thu, 15 Sep 2016 09:01:05 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;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.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BN1AFFO11FD033.mail.protection.outlook.com (10.58.52.246) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.619.6 via Frontend Transport; Thu, 15 Sep 2016 09:01:04 +0000 Received: from [127.0.0.1] (B32944-11.ap.freescale.net [10.232.14.25]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id u8F90uQ2011702; Thu, 15 Sep 2016 02:01:01 -0700 To: "Tan, Jianfeng" , 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> CC: , , From: Pankaj Chauhan Message-ID: <23bebfde-54ad-04fd-64cb-c99d7a4a78e9@nxp.com> Date: Thu, 15 Sep 2016 14:30:55 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131184036645867078; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(1109001)(1110001)(3190300001)(339900001)(24454002)(199003)(43544003)(76104003)(189002)(377454003)(11100500001)(54356999)(47776003)(76176999)(50986999)(97736004)(64126003)(65806001)(68736007)(5001770100001)(92566002)(4001350100001)(4326007)(189998001)(33646002)(83506001)(2950100001)(81166006)(8936002)(8676002)(81156014)(19580395003)(19580405001)(8666005)(65956001)(7846002)(356003)(305945005)(36756003)(2906002)(561944003)(31686004)(93886004)(50466002)(85426001)(104016004)(87936001)(5660300001)(7126002)(31696002)(105606002)(65826007)(86362001)(120886001)(586003)(106466001)(7246003)(23746002)(77096005)(626004)(230700001)(7059030)(41533002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB2441; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD033; 1:pJcJrl5uneRtsuUu9RfoxpUDN9qeKayZcn5LtJ9xhSyg6a/Cvx40gnXM1q39HkaaNwWlAcmixALA5+7BKO5G+OnvhyR3PjMFWKQYFgY5GSpt4qboH2zrYAObcOkqfrzwOBrvEg76+sqpKdtOUSeAQLJrlVfOlbzubcQ4wzMC563NB80uUAGV3HydCEshazpEjVrUePW3kcMxGo71YfAS1w5rJgKfmaNNTxnprIuu7DWk06LixyKii/s1IH3W24gO5q/aRSU9vzlmUQOeEiynukLgTbqmVOj/XntFLXD3dmTq4uu1cnHKTjdLa5wvoIMnZdiilfuZ9CylQcY6EODLqGdhdODhXBE1B/ymc6/7IBhMEjMHv6/KV4+0DcsspY+kXfMrz02a5FVXv50Mv4o3O803oElWfiunNY1hztI4AwZyRxgVFMGBKSEPwBG73P/axWvTTB8F6n8iJ5Et5n0Ae13Qm/tKE6KtEfCWUh62+WDUi8wmueaiD+tAwMHenlw36M2/vVdAeWOaLucYRfqMvAwX3dLIyqiljoeF2fKQaMFDoGcVw0RTo77BCkvj74NW7JT5v5Vfd8SDIaKfkrdWLJGP9KmAJ75kegAVw43zoLMQBPNA/ZHhuBA+vDGvRAE9g0uI0M40AtJjWlPC5YucSQ== X-MS-Office365-Filtering-Correlation-Id: 5306bd3c-1098-4107-2ce5-08d3dd46d2ef X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2441; 2:2IBU4RUsXBQSXWddp2OzZ2t6RhYiukPEfZMVEOD7cDzofDh1YB0/C7AvHw5aUiPlVd4AnShUySR4ETKgFIcJpbC4+BDCmNYbibNQPT7tlUiHIx2cAr40R6DaLMwKGMWmxaFG7nkZfUus3wy1vgbJCfkapzinErFt51gauQOFeRPCPyRekcUMaH8sLIWEAr0v; 3:R9EPj+TljxqPwF8qv6qBcTPS2My5LFuw909ZKdm0zTyO8gZ5tChLBq6TO7sJJJgDPLTdvQNbuvhzoGWbbHnom5kVEwnpC2sATuP5YcMRezpI3GetvbJTV8V8wRsm6c21HLzhnah/MJJrK4TH9j96ZurcK447qEqqjEa6msr4WBGKDgQeqnL6Yj0j+WC2Lz4zyO1PyiCk8Xsh+FaywXKPXzbOYnpD6gVGduKe+BdGqtE= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2441; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2441; 25:u9MUoK/rmcHzQop5GN3dIkIxVIOBHCf+Kof/U+mmcfBN/OZ7H6+OY9TjfgqSxtgEG7mrB33ogUEYobFWHi6HUMCbAWALHe61qdvSMnLNiOWXwM+2z5TwBPcdo3GjXlFhSyNa8kXBj0f36NqXhPpgOqp0t4k2PuSKPIUxhkCFEPzys6xniexjZ4VxDVUFgMozSSdGZMyEI/oIbSkVUEnCD2slAHFRBaomVGdE5Ln52zQnjcMvKCACrA6k0JPR/1ZnCvmLzLSK+j+Gz/h6CkHn3KjH9l9eYn9kYRRqd842o4xSfx2pjZw706KDJ9LzjUGBck6LYHjz5vrZfs03sk7Hdm8zKo6+X6KGRmxHU5ppLGwWRTQcxMnYVonJpbxhA9ROuH8143/5ZoQxKCHFXt9hw5Y3l+n+e9FHeBSI+v8BPUZ6YlhN7g5nGtm+NKI0sf/CwaUUYoRdTjtZBIOMiABJSIDTUGSyFMX/bBYqMfpajo8ueKxssddLjykBbMGZWheNsBRDKUyBS6aKaojIycw59yOGz/eFJvrODkuYNLNGyzmqgF/scgehrzDCFY3qpHmx0Of/X6CJzP4mvjaSMINqis5wN2blAMUAyUx9G2UL1qYs8kuBo5Xky+vSeuFgX5kMtZvf+zw5BAfD9G5T/tcLq3vvEG8uqNnBfxFm2Ka+PIVxaEhdmKz06CyZ7IsIF1JVLkhC4D+FodfgJm9j6uSX55SkFRCETky5e7ysyy4QCp5Zx5UTGWpHwHEHtGyzI6mb5dZGbXRTtvYF2u2Hvr4h2g== X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2441; 31:YGZXt82VkZF0af7IoxlPGKmLiPaST4MdSZFbDdPhIdtgoGVaDB7QCLInwNNwa+pCtwMV9NdHbBxvKFeW+VcVLgUEHcxm824aIimRVVoLVyxiGKb/DHeet9hxXNG9cCFelNNsXqzKk1eUT2a8CyboxQ+tynJEPXxzLHsxUi8Z6FtVNEwqclH58H340ncFj8UuoKK/nYEm7XmY9k3rCSZ1XJ4UwtENySgzskr4s2/Px2s=; 4:jGOm1eL3luuBc3q0YRgw5vMaSYpYzDHnyEaXaK7Z+ZMoG77XrwCioS3v+qKm5gZW2My38HqqY8oNos7K3uWjYTDQWllDYwhi9E6rVREg8ezubnO6dZOtIMM0zp4tG3oIFuODhaojn3mfIYKXiL87YB+AEJZTn0OY9p0XUyaJjbFRAO4BOwf6qp2tBsupjR+valrBf3ttuzgjICuitqNIMVeBYCuiV6Kl7JORFTNNoEK1gND6Zjy9CKHRfmxcJUmfQZ0oEOHfztiwfQqXiekVSteHHLJ33gUO16kCJnvwTTnqqXrufcFrgm2PzgFa3nsG1OGC9v/jKuuJMQ+E9xwVpyGE+G9cSd6iy6GB7+iIPv6A4V1mU7gnhj1z4hCsZJovt6gA2cIFNBJFc1/T7hDDhj1qtdpIQevcm9UhH4z9C2qXKCX+uVjDuwSoz2jRv6q/WcLE6bwzcSlZXLr9F3kx80Ft/Ef7EafugGKVkWA4DKKT/Jc0T5L+4KEAi6P2lDXWs5NMUV3d3bRPxxMgQkgsiUeTLVmVAk0VjP38QgQJ9UgoBxyRXPaUH9Uz9eDexHn1PAUVc33vUX40hEulvId5nQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(13024025)(13017025)(13015025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM5PR03MB2441; BCL:0; PCL:0; RULEID:(400006); SRVR:DM5PR03MB2441; X-Forefront-PRVS: 0066D63CE6 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM5PR03MB2441; 23:AqD+HWLRuGw+XU2NYTqBc/5faSAR6zlm28Doo?= =?Windows-1252?Q?I0frib3MxNN+4E5qDKD6rMjl4zF4fxEa/o2gCxa9eqjWD/duWenwmXVE?= =?Windows-1252?Q?4govSLN+KRHXVfy4nIykCFV+PNITK0Uqz8OZhk2apBiNCPTZMyzVW3sl?= =?Windows-1252?Q?0pQ6R3CqY5kaF9lwB+c9xSHhulf/afTNZNN9YLF1FjJnX/O/vb617kaN?= =?Windows-1252?Q?qXN2vNVceDKg8XOfwMEV2AsiFXOn/1Bm/zRcz2nv1hxPKEsR1Vcp7dX6?= =?Windows-1252?Q?51lu4lQ8yDLzR0t+3Ik+3JEUBMcmBU4jjf5SMSZ4qyxdemr/kR8rn9Ns?= =?Windows-1252?Q?35lxiUyurgSq0ftZG1nzlb7h4MCMnwXfIm4lgJkgnQo5+SR2fHHHHc4+?= =?Windows-1252?Q?J2pvRxNECc5VtoNr3aiVOK0g1771tOX1roR5ePvoIQ9OvNNpiqNJdZ4d?= =?Windows-1252?Q?RK6MFTk47nS63tTk7HP9g/HWz6diHqIhJ63a5J9W/7CXYRoAJgLTRHeW?= =?Windows-1252?Q?fE32D0m7/YIiDAXmjzC4LFn42Y10rSquDglFBALxobH2HukNd4n/+YjA?= =?Windows-1252?Q?CuIa3Lcz15TC6ktwcNbQ5P/RFMzqlMYdoBJ8KwWoGE3rFAQE1/3FCpmQ?= =?Windows-1252?Q?isVgX15hQX065JlgoGZ4V7fSzsHT6QoGYH392kYYKUA8AVrg8yDX8c5+?= =?Windows-1252?Q?SKhZjSTo6moQxcPd24mnSBLIBcx+7QGuf6xVyvUkO/XWkghJzvMOcv5y?= =?Windows-1252?Q?nZycsVgkTu0lUGNz+kDUObENrlKSxd/dY3o+7aiKBSIMkdXd+UwxHGaZ?= =?Windows-1252?Q?udIGqp73Dq6wIxrWIlJhmCQhZeqxvAHy5tKiKBQ56GJFL14AsoXhdLEP?= =?Windows-1252?Q?UP85suNK/GhmS00Jb1ZIQshuAgSyetrqaoHDy26PtUM9v4Ht/BZQXqD+?= =?Windows-1252?Q?vVTcZBqtajoJfYvdRGQMwlqbc2Q7ONJqbOmlP7KrAVMVA2HxTLb+/+I0?= =?Windows-1252?Q?PMKrOxW+Buk1Agxtaui3YU6jynsZxs2lxEsnzsIjhUMQoVDd9MpOPYuV?= =?Windows-1252?Q?UlQpwpoLdvDYsrkXHxJtf81HPCQ2hqjTiXevIRUERR4wSRJgncQQpuNy?= =?Windows-1252?Q?dowL3uqJ03XhrHAccsh+AqptJQdCKRNl/zFPGIZtX2LmG3ruFE87cHoZ?= =?Windows-1252?Q?qe18MAt2aSFa1RE+TcIy/Btn+Snj48QuWP7dgG4f95/limCk0pGkS75u?= =?Windows-1252?Q?V0fRzb3vLbfPIH5ZuvnHVx5z0qyPi2rWti83IVw/QShx6WkG5piJZdti?= =?Windows-1252?Q?6m+lp/f9EgF73ztNe0WOuuqzvicPc3MftcOrwMMqWLni54C5NDktSrHN?= =?Windows-1252?Q?k+qOrFPLDafZHhkcSuoK40AsjYV55XxRDu35FwfpsK+Xm9JB+u/oKW1O?= =?Windows-1252?Q?1SBUBkx0mBM5ZAs5vb+7fA98PGfGaAKGloBkG4xDuq+NXwxI6IZZHBEp?= =?Windows-1252?Q?L51n1PXqyjPgSe0VthCw5S7l0bg8E4iLe0ICvenvIsaEgxt0gVWsLSCa?= =?Windows-1252?Q?iH667rbVgod/YuyWV3SfkzOycLqoXF6EgFED59h6Wi4OauE9ohevEEyd?= =?Windows-1252?Q?zmaYaOdHrzxNqkoFUnX7LI/PGtS71VVxICf/zPvJrMp+WoQpSQyY/cdh?= =?Windows-1252?Q?hGu+aSrdQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2441; 6:jU26DNa9454HpKhJqVlmYHf3+FjSkWKrCo//3BzvMmbJKAL1ZmlYM9rnPqo+EbIX61i360QaEOhbYWawY87phAmpxOkyjD5/8WOjIteuVKjg49fulwKMkWCuLFaQOsyJBnCvLfS5QUeX6yn/2B7bCiEuapVyBRo26DnIbJSa7H72PX5FUFvA+KbcAG5geKAPzatfALhDFucI2BXACPp0CVxaXu7EuiCQk/uIeYwofKmbdVT+rlkPPErH6CkNM1MhT2O+bxYkJlB4I6E/sMLJHDgq6FprpkZboZwLmavwg1U=; 5:QsuAZgwpQ/ALbaqDer7+tuconU5D9lQLrnH2exYIkw9TWK8nrMenh//a73dc1J4YqkpU6hwUuYg7dV/yrPBj+np/rUz3G56KzFE23xYDALd6XFT9gJKysaCFJ9SX+4DsGGPdtVFn/gSAhI7uPo3KAxBJJQHCMRWLbjXELDE89gQ=; 24:C4p9NVFAwWAQf+JD/ZnoKFvEKoUvMPTj62MAQnFT9odtLf3Hl2HCTc3pan/De3QYrPe+sCZG192hXoDjkYpbtuCximnRkbC+V6g1Jl3Wg84=; 7:9DeNXbss4u41v+fEJhOwG3U7GpcTIjY4I52JFbNaPMJ4xsT4yaK8638nkpu/q8ums4RSK5I27sfQw6oparFOGmXNXL50MHsg1H3OZ3k9ZW0lTGqFFta7Rp+YURALJnBFZUpWTocGMTfvkn/Aoq4k44qRIHxVziIQu3seb7nw/pYGfEEKnZwQZmY9eLLq+bfKx5qB5qbzSb/rO1TqpUJD//P2p+hiKrlw7dWomRNkcbLG9NnYilJaGa7zOWDzNGh9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2016 09:01:04.2903 (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.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2441 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: Thu, 15 Sep 2016 09:01:07 -0000 On 9/13/2016 12:21 PM, Tan, Jianfeng wrote: Hi Jianfeng, >>> >>> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote: >>>> Introduce support for a generic framework for handling of switching >>>> between >>>> physical and vhost devices. The vswitch framework introduces the >>>> following >>>> concept: >>>> >>>> 1. vswitch_dev: Vswitch device is a logical switch which can have >>>> physical and >>>> virtio devices. The devices are operated/used using standard rte_eth >>>> API for >>>> physical devices and lib_vhost API for vhost devices, PMD API is not >>>> used >>>> for vhost devices. >>>> >>>> 2. vswitch_port: Any physical or virtio device that is added to >>>> vswitch. The >>>> port can have its own tx/rx functions for doing data transfer, which >>>> are exposed >>>> to the framework using generic function pointers >>>> (vs_port->do_tx/do_rx). This way >>>> the generic code can do tx/rx without understanding the type of device >>>> (Physical or >>>> virtio). Similarly each port has its own functions to select tx/rx >>>> queues. The framework >>>> provides default tx/rx queue selection functions to the port when port >>>> is added >>>> (for both physical and vhost devices). But the framework allows the >>>> switch implementation >>>> to override the queue selection functions (vs_port->get_txq/rxq) if >>>> required. >>>> >>>> 3. vswitch_ops: The ops is set of function pointers which are used to >>>> do operations >>>> like learning, unlearning, add/delete port, lookup_and_forward. The >>>> user of vswitch >>>> framework (vhost/main.[c,h])uses these function pointers to perform >>>> above mentioned >>>> operations, thus it remains agnostic of the underlying implementation. >>>> >>>> Different switching logics can implement their vswitch_device and >>>> vswitch_ops, and >>>> register with the framework. This framework makes vhost-switch >>>> application scalable >>>> in terms of: >>>> >>>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h] >>>> 2. Number of ports. >>>> 3. Policies of selecting ports for rx and tx. >>>> >>>> Signed-off-by: Pankaj Chauhan >>> >>> After this patch set, how's mapping relationship between cores and >>> vswitch_dev? Old vhost example does not have the concept of switch, so >>> each core is binded with some VDEVs. Now, we still keep original logic? >>> >>> (a) If yes, provided that phys device could has no direct relationship >>> with vdevs in other switching logics, we may need to bind those physical >>> devices to cores too? In that case, switch_worker() will receiving pkts >>> from all devices (phys or virtual) and dispatch, which looks like: >>> >>> switch_worker() { >>> FOR each port binding to this core { >>> rx(port, pkts[], count); >>> vs_lookup_n_fwd( information_needed ); >>> } >>> } >> >> Since we support only one switch device running at one time. We bind >> the ports of the switchdev to the core. But The switch might have it's >> own logic to bind the port to the core. For example >> VMDQ only supports one Physical port, other switch can support more >> than one Physical port. In order to take care of that i have added two >> ops in swithdev_ops: >> >> 1. vs_sched_rx_port: >> >> struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum >> vswitch_port_type ptype, >> uint16_t core_id) >> >> 2. vs_sched_tx_port: >> >> struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum >> vswitch_port_type ptype, uint16_t >> core_id) >> >> The idea of providing these functions is that vhost/main requests the >> underlying switch implementation to schedule a port for rx or Tx, the >> current running core_id is also passed as parameter. So the switch can >> take a decision which port to do rx or tx based on core id, and may be >> some other custom policy. >> >> For example VMDQ always returns the one single Physical port in >> response to these functions called from any core. The other switch >> can return the ports bound to the cores. >> >> Similarly there are two port operations (vs_port->get_rxq and >> vs_port->get_txq), here also we pass core_id as parameter so that >> the underlying switch implementation can schedule the rx or tx queue >> based on the core_id. >> >> The above mentioned ops are used in drain_eth_rx() and >> do_drain_mbuf_table() (main.c) currently, and they leave binding of >> physical port and the queues to the underlying implementation. This >> way we can accommodate VMDQ which uses only one physical port and >> rxqueues based on VMDQ, OR any other switch which uses multiple >> physical port and rx/tx queue scheduling based on some other logic. >> >> Please suggest if this way of scheduling ports and tx/rx queues is >> fine or not? > > According to above explanation, in VMDQ switch, we cannot schedule two > queues (belongs to the same port) on the same core, right? > Yes. This would be a limitation i believe which will not be acceptable. The method that you suggested further in the email (tread port + queue_id as a vs_port) can solve this. > >>> >>> (b) If no, we may bind each core with n switches? If so, switch_worker() >>> also need to be reworked to keep receiving pkts from all ports of the >>> switch, and dispatch. >>> >>> switch_worker() { >>> FOR each switch binding to this core { >>> FOR each port of switch { >>> rx(port, pkts[], count); >>> vs_lookup_n_fwd( information_needed ); >>> } >>> } >>> } >> Since we currently support only one switch_dev in a running instance of >> vhost_switch() we can use binding of ports to core as you suggested in >> #(a). > > OK. > >> >>> >>> In all, (1) we'd better not use vdev to find phys dev in switch_worker >>> any more; >> >> I agree with you. I have tried to do following in drain_eth_rx (): >> >> >> core_id = rte_lcore_id(); >> rx_port = vs_sched_rx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, >> core_id); >> if (unlikely(!rx_port)) >> goto out; >> >> rxq = rx_port->get_rxq(rx_port, vdev, core_id); >> rx_count = rx_port->do_rx(rx_port, rxq, NULL, pkts, >> MAX_PKT_BURST); >> >> Here we don't assume any relation between vdev and the physical device >> or rxq. But pass vdev to the underlying switch so that it can choose >> the rxq for this vdev. In case of VMDQ it will return VMDQ queue >> number for this vdev. In case of any other switch implementation it >> can have their own logic to decide rxq. > > Thanks for explanation. > >> >> (2) we'd better not differentiate phys device and virtual >>> 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. > 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? Thanks for wonderful suggestion! Yes it should be possible, instead of having one vs_port for physical device we could create one vs_port for each phys device + queue_id combination. Then we can bind the vs_ports to the cores, and do away with binding vdevs to the cores. In order to add extra vs_ports (port + queue_id) there are two methods: 1. vhost/main.c (or vswitch_common.c) queries the underlying switch about how many rx queues to support thourgh a new accessor. VMDQ will return the number of vmdq queues, in this case. After getting the number of rx queues, vhost/main.c creates the extra ports i.e one vs_port for each physical port and queue id combination. 2. Second method is that the switch implementation for example vmdq.c create the extra ports (port + queue_id) as part of vs_port->add_port operation for the physical port. Which method do you think we should follow? I think #1 should be done so that same logic can be used for other switches also. > >> >> vs_lookup_n_fwd(rx_port, pkts, rx_count, rxq); >> >> } >> >> Here i have two problems in achieving switch_worker as mentioned above: >> >> 1. while doing Rx from physical port, we need the associated vdev to >> know the VMDQ rx_q. That was the reason i kept current logic of >> keeping vdevs bound to the core in the switch_worker. If we don't >> keep list of vdevs assigned to the core, how we' will get the rxq on >> phsyical device in case of VMDQ switch implementation. > > I think my proposal above can solve this problem. Yes thanks! > >> >> 2. drain_mbuf_table() currently assumes that there is only one >> physical device on which we have to transmit. We may have to rethink >> where to keep the tx queues (&lcore_tx_queue[core_id]), i case we have >> multiple physical ports we might have to move tx queues to each port. > > This function, drain_mbuf_table(), and its related data structures, are > used for cache on tx direction. But it's not only useful for physical > port, but also virtual port (vhost_dev). I suggest to make such cache a > field of per vswitch_port. And each again, all vswitch_ports are > connected to a core, each core will periodically clean those vswitch_ports. > okay. So we add similar tx_q structures (one per core) to each vswitch_port, correct? Thanks, Pankaj