From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AA68FA04B3; Mon, 16 Dec 2019 09:46:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F174C1C195; Mon, 16 Dec 2019 09:46:54 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 0D3D31C191 for ; Mon, 16 Dec 2019 09:46:54 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 840EF280066; Mon, 16 Dec 2019 08:46:52 +0000 (UTC) Received: from [192.168.38.17] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 16 Dec 2019 08:46:43 +0000 To: Matan Azrad , Tiwei Bie , "Thomas Monjalon" CC: Ori Kam , "Liang, Cunming" , "Wang, Xiao W" , "maxime.coquelin@redhat.com" , "Wang, Zhihong" , "Yigit, Ferruh" , Shahaf Shuler , "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso , Olga Shern References: From: Andrew Rybchenko Autocrypt: addr=arybchenko@solarflare.com; keydata= mQINBF2681gBEACbdTxu8eLL3UX2oAelsnK9GkeaJeUYSOHPJQpV7RL/iaIskqTwBRnhjXt7 j9UEwGA+omnOmqQMpeQTb/F9Ma2dYE+Hw4/t/1KVjxr3ehFaASvwR4fWJfO4e2l/Rk4rG6Yi 5r6CWU2y8su2654Fr8KFc+cMGOAgKoZTZHZsRy5lHpMlemeF+VZkv8L5sYJWPnsypgqlCG3h v6lbtfZs+QqYbFH6bqoZwBAl5irmxywGR7ZJr1GLUZZ1lfdazSY8r6Vz0/Ip/KVxGu2uxo81 QCsAj0ZsQtwji9Sds/prTiPrIjx8Fc/tfbnAuVuPcnPbczwCJACzQr4q26XATL3kVuZhSBWh 4XfO/EAUuEq5AemUG5DDTM87g7Lp4eT9gMZB6P+rJwWPNWTiV3L7Cn+fO+l9mTPnOqdzBgDe OaulKiNSft1o0DY4bGzOmM2ad2cZt0jfnbMPMTE9zsr6+RFa+M8Ct20o6U1MUE4vP6veErMK of4kZ8PdoMM+Sq1hxMPNtlcVBSP9xMmdSZPlfDYI5VWosOceEcz7XZdjBJKdwKuz70V7eac4 ITSxgNFCTbeJ03zL2MR5s0IvD9ghISAwZ6ieCjU5UATn5+63qpD0nVNLsAdb/UpfvQcKAmvj 0fKlxu/PMVkjBa7/4cfNogYOhWDKUO+1pMaFwvb6/XTo6uMpfQARAQABtCxBbmRyZXcgUnli Y2hlbmtvIDxhcnliY2hlbmtvQHNvbGFyZmxhcmUuY29tPokCVAQTAQoAPhYhBP6NPgcKRj/Y X0yXQahue0sAy4m+BQJduvNYAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKhue0sAy4m+t3gP/j1MNc63CEozZo1IZ2UpVPAVWTYbLdPjIRdFqhlwvZYIgGIgIBk3ezKL K0/oc4ZeIwL6wQ5+V24ahuXvvcxLlKxfbJ6lo2iQGC7GLGhsDG9Y2k6sW13/sTJB/XuR2yov k5FtIgJ+aHa1PDZnepnGGOt9ka9n/Jzrc9WKYapOIIyLRe9U26ikoVgyqsD37PVeq5tLWHHA NGTUKupe9G6DFWidxx0KzyMoWDTbW2AWYcEmV2eQsgRT094AZwLFN5ErfefYzsGdO8TAUU9X YTiQN2MvP1pBxY/r0/5UfwV4UKBcR0S3ZvzyvrPoYER2Kxdf/qurx0Mn7StiCQ/JlNZb/GWQ TQ7huduuZHNQKWm7ufbqvKSfbPYvfl3akj7Wl8/zXhYdLqb5mmK45HXrgYGEqPN53OnK2Ngx IgYKEWr05KNv09097jLT5ONgYvszflqlLIzC4dV245g7ucuf9fYmsvmM1p/gFnOJBJL18YE5 P1fuGYNfLP+qp4WMiDqXlzaJfB4JcinyU49BXUj3Utd6f6sNBsO8YWcLbKBV9WmA324S3+wj f4NPRp3A5E+6OmTVMLWire2ZvnYp3YvifUj1r8lhoZ2B2vKuWwiTlHOKYBEjnOQJQnqYZEF0 JQQ1xzVDBQKE01BPlA3vy6BGWe6I4psBVqMOB9lAev/H+xa4u6Z3uQINBF269JsBEAC2KB3W 8JES/fh74avN7LOSdK4QA7gFIUQ4egVL81KnxquLzzilABuOhmZf3Rq6rMHSM8xmUAWa7Dkt YtzXStjEBI/uF0mAR3mMz1RcL2Wp+WD/15HjVpA7hPjXSEsWY0K2ymPerK4yrLcfFTHdMonY JfuACCC9NtOZxrWHOJoUS+RT7AWk80q/6D2iwQ47/2dBTznVG+gSeHSes9l91TB09w6f9JX/ sT+Ud0NQfm7HJ7t2pmGI9O6Po/NLZsDogmnIpJp/WwYOZN9JK7u2FyX2UyRzR8jK42aJkRsh DXs16Cc2/eYGakjrdO3x9a+RoxN7EuFtYhGR1PzMXdUiB5i+FyddYXkYUyO43QE/3VPA5l1v TUOagzZq6aONsdNonGJkV3TIG3JmUNtM+D/+r6QKzmgoJ8w576JxEZI09I/ZFN+g7BnUmlMx 6Z3IUOXVX/SWfGFga0YajwajHz03IBhChEbYbbqndVhmshu2GFURxrfUPYWdDXEqkh+08a5U Didia9jm2Opv4oE1e1TXAePyYJl/Zyps4Cv00GObAxibvMBQCUZQ+IBnNldRBOwXXRQV2xpx P+9iO1VYA/QXn0KqRK+SH1JGRXbJYi42YFaW1gE0EU0fiR2Wb9pK+doNEjjOhlzUGuvOEAUS +4m0m3dlfEvpCV9GMr7ERRpZzh9QkQARAQABiQI8BBgBCgAmFiEE/o0+BwpGP9hfTJdBqG57 SwDLib4FAl269JsCGwwFCQlmAYAACgkQqG57SwDLib7x6g//e+eCtNnJz7qFGbjWRJYNLCe5 gQwkhdyEGk4omr3VmjGj3z9kNFy/muh4pmHUngSAnnpwZggx14N4hhKf9y8G4Dwvsqa6b1zB Jq/c4t/SBDtGW4M/E331N04PaQZpcrbTfp1KqHNknk2N7yOk4CcoLVuIZmA5tPguASV8aAfz ZwhWAwn6vUEw9552eXEAnGFGDTCbyryNwzB5jtVQOEEDjTxcCkpcXMB45Tb1QUslRTu/sBAe HhPCQSUcJHR+KOq+P6yKICGAr291PZd6Qc7C3UyE+A3pY/UfdEVWj0STBWx1qvYLaHLrI4O9 KXDgh7luLjZZafcueCaPYmNo4V2lmNb3+7S4TvqhoZS+wN+9ldRQ4gH3wmRZybN6Y/ZCqxol RaZpE3AqdWsGvIgAkD0FpmtZNii9s2pnrhw0K6S4t4tYgXGTossxNSJUltfFQZdXM1xkZhtv dBZuUEectbZWuviGvQXahOMuH2pM64mx2hpdZzPcI2beeJNHkAsGT2KcaMETgvtHUBFRlLVB YxsUYz3UZmi2JSua4tbcGd6iWVN90eb8CxszYtivfpz6o2nPSjNwg0NaVGSHXjAK0tdByZ9t SkwjC3tEPljVycRSDpbauogOiAkvjENfaPd/H26V5hY822kaclaKDAW6ZG9UKiMijcAgb9u5 CJoOyqE8aGS5Ag0EXbr1RwEQAMXZHbafqmZiu6Kudp+Filgdkj2/XJva5Elv3fLfpXvhVt0Y if5Rzds3RpffoLQZk9nPwK8TbZFqNXPu7HSgg9AY7UdCM94WRFTkUCGKzbgiqGdXZ7Vyc8cy teGW+BcdfQycDvjfy50T3fO4kJNVp2LDNdknPaZVe8HJ80Od63+9ksB6Ni+EijMkh6Uk3ulB CSLnT4iFV57KgU2IsxOQVLnm+0bcsWMcCnGfphkY0yKP+aJ6MfmZkEeaDa7kf24N14ktg50m vOGDitcxA/+XXQXOsOIDJx1VeidxYsQ2FfsKu1G8+G6ejuaLf4rV5MI/+B/tfLbbOdikM5PF pxZVgTir9q13qHumMxdme7w5c7hybW412yWAe9TsrlXktFmFjRSFzAAxQhQSQxArS6db4oBk yeYJ59mW52i4occkimPWSm/raSgdSM+0P6zdWUlxxj+r1qiLgCYvruzLNtp5Nts5tR/HRQjE /ohQYaWDSVJEsc/4eGmgwzHzmvHtXeKkasn01381A1Lv3xwtpnfwERMAhxBZ8EGKEkc5gNdk vIPhknnGgPXqKmE1aWu8LcHiY+RHAF8gYPCDMuwyzBYnbiosKcicuIUp0Fj8XIaPao6F+WTi In4UOrqrYhsaCUvhVjsTBbNphGih9xbFJ8E+lkTLL8P3umtTcMPnpsB4xqcDABEBAAGJBHIE GAEKACYWIQT+jT4HCkY/2F9Ml0GobntLAMuJvgUCXbr1RwIbAgUJCWYBgAJACRCobntLAMuJ vsF0IAQZAQoAHRYhBNTYjdjWgdaEN5MrAN+9UR5r/4d3BQJduvVHAAoJEN+9UR5r/4d3EiQP /3lyby6v49HTU94Q2Fn2Xat6uifR7kWE5SO/1pUwYzx6v+z5K2jqPgqUYmuNoejcGl0CTNhg LbsxzUmAuf1OTAdE+ZYvOAjjKQhY4haxHc4enby/ltnHfWJYWJZ9UN5SsIQLvITvYu6rqthO CYjpXJhwkj3ODmC9H1TrvjrBGc6i7CTnR8RCjMEwCs2LI2frHa4R6imViEr9ScMfUnzdABMQ B0T5MOg8NX92/FRjTldU2KovG0ML9mSveSvVHAoEBLy4UIs5nEDdNiO1opJgKb5CXvWQugub 7AR52phNdKVdEB0S4tigJT4NalyTaPiUhFEm+CzZpMQDJ5E+/OowaPRfN4HeJX+c8sB+vUAZ mkAaG75N+IEk5JKFK9Z+bBYgPgaBDFZYdWDB/TMH0ANt+KI5uYg0i12TB4M8pwKG1DEPUmWc F2YpvB3jnbwzsOpSFiJOOlSs6nOB0Sb5GRtPOO3h6XGj+6mzQd6tcL63c9TrrUkjq7LDkxCz SJ2hTYRC8WNX8Uw9skWo5728JNrXdazEYCenUWmYiKLNKLslXCFodUCRDh/sUiyqRwS7PHEA LYC/UIWLMomI0Yvju3KA5v3RQVXhL+Gx2CzSj3GDz9xxGhJB2LfRfjzPbTR/Z27UpjCkd8z0 Ro3Ypmi1FLQwnRgoOKDbetTAIhugEShaLTITzJAP/iRDJCQsrZah5tE8oIl81qKEmBJEGcdt HYikbpQe7ydcXhqTj7+IECa3O7azI5OhCxUH2jNyonJ/phUslHH2G1TTBZK8y4Hrx5RpuRNS esn3P9uKu9DHqBAL7DMsCPwb2p1VNnapD72DBmRhzS/e6zS2R4+r9yNv03Hv7VCxKkmtE63H qpS//qpjfrtsIcHAjnKDaDtL1LYCtHoweI+DOpKKULSAYp/JE6F8LNibPQ0/P3S5ZIJNC4QZ uESjFOalJwFIqGQdkQB7ltRNJENLrHc+2jKGOuyFHm/Sbvp5EMGdaeQ0+u8CY0P+y6oXenwx 7WrJz/GvbNoFhJoJ6RzxCMQrFgxrssVZ7w5HcUj94lbnJ6osdYE/WpSd50B6jet6LKh5revg u9XI9CoqsPQ1V4wKYYdllPuogCye7KNYNKuiiuSNpaF4gHq1ZWGArwZtWHjgc2v3LegOpRQF SwOskMKmWsUyHIRMG1p8RpkBQTqY2rGSeUqPSvaqjT0nq+SUEM6qxEXD/2Wqri/X6bamuPDb S0PkBvFD2+0zr5Bc2YkMGPBYPNGZiTp3UjmZlLfn3TiBKIC92jherY563CULjSsiBEJCOSvv 4VPLn5aAcfbCXJnE3IGCp/hPl50iQqu7BPOYBbWXeb9ptDjGCAThNxSz0WAXkmcjAFE8gdE6 Znk9 Message-ID: <17d5139b-3c7c-5ce2-1d2a-a86533a8bc2f@solarflare.com> Date: Mon, 16 Dec 2019 11:46:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-25106.003 X-TM-AS-Result: No-16.918400-8.000000-10 X-TMASE-MatchedRID: IeZYkn8zfFo9gZmQY0RBhPZvT2zYoYOwC/ExpXrHizwrxUs8Nw/2fveH aPJtCROSsMJ7b2uLM6MA3asjxPPROYH/9PEJqVb6uwdUMMznEA9DxJKuWK52WhbozYDXkvVA09a iYl89hBlbP6BosQ0i7++ctL26ncb67J5Y8+CswhjM0ihsfYPMYRNxIBdPjFbg2sx4YoEobCrs5+ nhNoK8J61MQCh+Oqyb+DmW3CNy7eUvwcx4DcVB2x3EEAbn+GRbwwD0mzFpRreRoQLwUmtov3jaz XnP+4i4It5IoIlYJUlU0/VpWJMnTkHWWYQjqKYFyZHnIMmQ+Dj5qGeseGYAlI5JUK9UdYknhHhE srkbWKF5tpUfNWF/M7ojBpRNME6EIGlXtVl7j/5VSuxV4oNBd2piq4KsutXCL+H1U69PoCCRHno f8YOK/W5Q+93YZJmsZV33nMkX4srfCKPGzKbWHZGzIhDiMWXrj87/LK+2sqMU+n0UrUxQO0Xbem j/Vs4qKem1U0hJhx/zDjUqc3ZoDBVw3TOpJLSU20204SCJw/oQOcMSo0926nDufZqx8z9XVzYyF bnMia+LBEBlB1GfMwknKFyXu/mD2vb713uVhGsmZusHWPhfCvioIsi7Sa0gf//XOd24EV3V102r pnc2Z8eGY6wUM4zg+utT0uMDJ18xotZUXfwLlGgws6g0ewz2TJDl9FKHbrk4j6y4YLH4VZjLgvU lcRRN5KUhPiJuHzNuyw+sIuHMAjvVCQ62diEAt0cS/uxH87A8jmaHmXQMAC9kwp67RNMu8ObHyx qaWGI1pZVQKcZLt024rDL/P7srsUqd0Uznu0ueAiCmPx4NwFkMvWAuahr83Mh122xXdCt4N1jhR VQFLaxZXRt2R/g5kUOZgKFtj8TIxLvf0o4PjWTrTHkFx0L3vD1M7NJhwgA9h7U3czEnPw== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.918400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25106.003 X-MDID: 1576486013-Mkeo0rTZEaik Subject: Re: [dpdk-dev] discussion: creating a new class for vdpa drivers 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/16/19 11:29 AM, Matan Azrad wrote: > > Hi all > > I understand all of you agree \ not object with the new class for vdpa drivers. I have two control questions: 1. If so, is it allowed to have vDPA driver in drivers/net/ if it is better from code sharing point of view? 2. If drivers/common is used, is exported functions which are used by drivers/net/ and drivers/vdpa/ and data structures are a part of public API/ABI? Hopefully not, but I'd like to double-check and ensure that it is solved in the case of shared libraries build. > Based on that, I'm going to start it. > > From: Tiwei Bie >> On Tue, Dec 10, 2019 at 09:00:33AM +0100, Thomas Monjalon wrote: >>> 10/12/2019 03:41, Tiwei Bie: >>>> On Mon, Dec 09, 2019 at 02:22:27PM +0300, Andrew Rybchenko wrote: >>>>> On 12/9/19 1:41 PM, Ori Kam wrote: >>>>>> From: Andrew Rybchenko >>>>>>> On 12/8/19 10:06 AM, Matan Azrad wrote: >>>>>>>> From: Andrew Rybchenko >>>>>>>>> On 12/6/19 8:32 AM, Liang, Cunming wrote: >>>>>>>>>> From: Bie, Tiwei >>>>>>>>>>> On Thu, Dec 05, 2019 at 01:26:36PM +0000, Matan Azrad wrote: >>>>>>>>>>>> Hi all >>>>>>>>>>>> >>>>>>>>>>>> As described in RFC “[RFC] net: new vdpa PMD for Mellanox >>>>>>>>>>>> devices”, a new vdpa drivers is going to be added for >>>>>>>>>>>> Mellanox devices – mlx5_vdpa >>>>>>>>>>>> >>>>>>>>>>>> The only vdpa driver now is the IFC driver that is located >>>>>>>>>>>> in net >>>>>>> directory. >>>>>>>>>>>> >>>>>>>>>>>> The IFC driver and the new mlx5_vdpa driver provide the >>>>>>>>>>>> vdpa ops >>>>>>> and >>>>>>>>>>>> not the eth_dev ops. >>>>>>>>>>>> >>>>>>>>>>>> All the others drivers in net provide the eth-dev ops. >>>>>>>>>>>> >>>>>>>>>>>> I suggest to create a new class for vdpa drivers, to move >>>>>>>>>>>> IFC to this class and to add the mlx5_vdpa to this class too. >>>>>>>>>>>> >>>>>>>>>>>> Later, all the new drivers that implements the vdpa ops >>>>>>>>>>>> will be added to the vdpa class. >>>>>>>>>>> >>>>>>>>>>> +1. Sounds like a good idea to me. >>>>>>>>>> +1 >>>>>>>>> >>>>>>>>> vDPA drivers are vendor-specific and expected to talk to vendor >> NIC. I.e. >>>>>>>>> there are significant chances to share code with network drivers >> (e.g. >>>>>>> base >>>>>>>>> driver). Should base driver be moved to drivers/common in >>>>>>>>> this case or is >>>>>>> it >>>>>>>>> still allows to have vdpa driver in drivers/net together with ethdev >> driver? >>>>>>>> >>>>>>>> Yes, I think this should be the method, shared code should be >>>>>>>> moved to >>>>>>> the drivers/common directory. >>>>>>>> I think there is a precedence with shared code in common which >>>>>>>> shares a >>>>>>> vendor specific code between crypto and net. >>>>>>> >>>>>>> I see motivation behind driver/vdpa. However, vdpa and net >>>>>>> drivers tightly related and I would prefer to avoid extra >>>>>>> complexity here. Right now simplicity over-weights for me. >>>>>>> No strong opinion on the topic, but it definitely requires >>>>>>> better and more clear motivation why a new class should be >>>>>>> introduced and existing drivers restructured. >>>>>>> >>>>>> >>>>>> Why do you think there is extra complexity? >>>>> >>>>> Even grep becomes a bit more complicated J >>>>> >>>>>> I think from design correctness it is more correct to create a dedicated >> class for the following reasons: >>>>>> 1. All of the classes implements a different set of ops. For >>>>>> example the cryptodev has a defined set of ops, same goes for the >> compress driver and the ethdev driver. Each ones of them has different ops. >> Going by this definition since VDPA has a different set of ops, it makes sense >> that it will be in a different class. >>>>>> >>>>>> 2. even that both drivers (eth/vdpa) handle traffic from the nic >>>>>> most of the code is different (the difference is also dependent on the >> manufacture) So even the shared code base is not large and can be shared >> using the common directory. For example ifc doesn't have any shared code. >>>>>> >>>>>> What do you think? >>>>> >>>>> The true reason is: if the difference in ops implemented is a key >>>>> difference which should enforce location in different directories. >>>>> Or underlying device class is a key. >>>>> Roughly: >>>>> - net driver is a control+data path >>>>> - vdpa driver is a control path only My fear is that control path >>>>> will grow more and more (Rx mode, RSS, filters and so on) >>>> >>>> I think this is a reasonable concern. >>>> >>>> One thing needs to be clarified is that, the control path (ops) in >>>> vdpa driver is something very different with the control path in net >>>> driver. vdpa is very generic (or more precisely vhost-related), >>>> instead of network related: >>>> >>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >>>> >> thub.com%2FDPDK%2Fdpdk%2Fblob%2Faef1d0733179%2Flib%2Flibrte_vhos >> t%2F >>>> rte_vdpa.h%23L40- >> L78&data=02%7C01%7Cmatan%40mellanox.com%7Cfac15 >>>> >> 729a67c4c81ee7608d77d7434a2%7Ca652971c7d2e4d9ba6a4d149256f461b%7C >> 0%7 >>>> >> C0%7C637115810358231304&sdata=%2BZa39vxadtKx5Ov7vmqcU3RuZhz >> kOP9o >>>> 8roEB0d5j6M%3D&reserved=0 >>>> >>>> It's built on top of vhost-user protocol, manipulates virtqueues, >>>> virtio/vhost features, memory table, ... >>>> >>>> Technically, it's possible to have blk, crypto, ... >>>> vdpa devices as well (we already have vhost-user-blk, >>>> vhost-user-crypto, ...). >>>> >>>> But network specific features will come eventually, e.g. RSS. One >>>> possible way to solve it is to define a generic event callback in >>>> vdpa ops, and vdpa driver can request the corresponding info from >>>> vhost based on the event received. >>>> >>>> Another thing needs to be clarified is that, the control path >>>> supposed to be used by DPDK apps directly in vdpa should always be >>>> generic, it should just be something like: >>>> >>>> int rte_vdpa_find_device_id(struct rte_vdpa_dev_addr *addr); int >>>> rte_vhost_driver_attach_vdpa_device(const char *path, int did); int >>>> rte_vhost_driver_detach_vdpa_device(const char *path); ... >>>> >>>> That is to say, users just need to bind the vdpa device to the vhost >>>> connection. The control path ops in vdpa is supposed to be called by >>>> vhost-library transparently based on the events on the vhost-user >>>> connection, i.e. >>>> the vdpa device will be configured (including RSS) by the guest >>>> driver in QEMU "directly" via the vhost-user protocol instead of the >>>> DPDK app in the host. >>> >>> Tiwei, in order to be clear, >>> You think vDPA drivers should be in drivers/vdpa directory? >> >> I was just trying to clarify two facts in vDPA to address Andrew's concern. >> And back to the question, to make sure that we don't miss anything >> important, (although maybe not very related) it might be helpful to also >> clarify how to support vDPA in OvS at the same time which isn't quite clear to >> me yet.. >> >> Regards, >> Tiwei >> >>> >>>