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 8872FA04B3; Mon, 16 Dec 2019 10:40:05 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 280EF1BF92; Mon, 16 Dec 2019 10:40:05 +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 710C71BF91 for ; Mon, 16 Dec 2019 10:40:03 +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 DB68A280064; Mon, 16 Dec 2019 09:40:01 +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 09:39:52 +0000 To: Maxime Coquelin , Matan Azrad , Tiwei Bie , Thomas Monjalon CC: Ori Kam , "Liang, Cunming" , "Wang, Xiao W" , "Wang, Zhihong" , "Yigit, Ferruh" , "Shahaf Shuler" , "dev@dpdk.org" , "Slava Ovsiienko" , Asaf Penso , "Olga Shern" References: <17d5139b-3c7c-5ce2-1d2a-a86533a8bc2f@solarflare.com> <186093dc-5330-965e-5283-4432b7e996f3@redhat.com> 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: <7a420216-1e20-3ffc-de09-ec62bba592d3@solarflare.com> Date: Mon, 16 Dec 2019 12:39:42 +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: <186093dc-5330-965e-5283-4432b7e996f3@redhat.com> 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.820300-8.000000-10 X-TMASE-MatchedRID: IeZYkn8zfFrmLzc6AOD8DfHkpkyUphL9/C3FULE80O8rxUs8Nw/2fveH aPJtCROSsMJ7b2uLM6MA3asjxPPROYH/9PEJqVb6uwdUMMznEA9DxJKuWK52WhbozYDXkvVAtMw sacuGxGlfTEimEz46ByI8bhIN1luKJVWqk0NljVxZMZ6MZ0H1Uitc78OfBHnLu2c6BBGcLozwVK uSbLr8Ulu26vYMGWggOVkOuCV4/Z4nmCeHyLMZHoSzHD2R/d28G0Oe0T+pTlFQKAQSutQYXLbmP rU3umuKP/VPO20ow0tT4B/w/6fIKae6jDzI71t5/1dEgwtQ6NA1X1Ls767cpnPW+p0zOs/DxD2a MvScTk49F5GaCy1xkZGMbxV80b6VL61O1NzZqANsExK7i/Tm0yejaijE212m1kam2JlgjVWq8Z1 C/6pqKIHIEhKC7bdo2Via0E1bchsJhm6TjE4vNRn0wrEetTLhqQd+Hs7Yv7u2rF0FMhg2hKUTuB Q/WRv/imI673FRLGI3T0rgzjaXFahQ86kFnIysyl2yL95kDWP17lqbebntfd2WHoowBULX75T4B PuNkdrG5X1ytJtmJLXGiT9EJcusioQNoRtg06t1e7Xbb6Im2kqAhuLHn5fEV4i674aSi3w6NElx I4H6Erb6dcCEWuPe5nMEaNU/RQTNij1CD60V+aygL0j4rnchhd8j8ZUaFpiE2ut4EHvMmXLpjZO zqCLFIWQb4fXTi111VEmx7sTk/3m+mKuSFu12YKm742WlIN6VLkhtDy7dOuZMicrOlIVJfWlr04 vVSkonQQ9aI0nnpd4qQlaRq90mMLxnrIEe9UGeAiCmPx4NwFkMvWAuahr83Mh122xXdCt4N1jhR VQFLaxZXRt2R/g5pT65zSOm+8nSPk7JBgwGNM0xwEqcioYIIJ14Rb4IjmUSX2bDqKS/Lg== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.820300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25106.003 X-MDID: 1576489202-GSOp_aexc_13 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" Hi Maxime, On 12/16/19 11:50 AM, Maxime Coquelin wrote: > Hi Andrew, > > On 12/16/19 9:46 AM, Andrew Rybchenko wrote: >> 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? > > If it has something to share, I think we should move the common bits > to the common directory. Does it mean that it is *not* allowed to have vdpa driver in drivers/net/ and vDPA drivers *must* live in drivers/vdpa only? >> 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. > > Common functions and data should not be part of the API/ABI I agree. > I guess we should use relative paths for including the common headers. Hopefully include_directories() with relative path in the case of meson.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 >>>> >>>>> >>>>> >> >