From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id D91CD2BB8 for ; Tue, 26 Feb 2019 14:36:06 +0100 (CET) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190226133605euoutp0265b4ff69a54a47edefa227294ff39501~G7WsQWI1F1468214682euoutp02Q for ; Tue, 26 Feb 2019 13:36:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190226133605euoutp0265b4ff69a54a47edefa227294ff39501~G7WsQWI1F1468214682euoutp02Q DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1551188165; bh=EY3s3T1DT9mtcTRc1YfkoZg8lPdfgi7rt/sBVHoKJd8=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=tWIp1Lz4o5GUDeBToSoqdudez9/Y3YW5ywB9pB/ixuk24KC4vCyajN/u838Y8ZP+n BNbBW8oiDpVgGpQdtHN0lISDBnTSaI3EcQ2IO+Y758MSw+lonUD0zqd4PZgP533olo GvnndOLrFzXYr9B4bAIZIxSZzldaa9q5CwLsESpM= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20190226133605eucas1p1af7979c74d6b46d03143156bb558c935~G7Wrv0Z-K0198401984eucas1p1S; Tue, 26 Feb 2019 13:36:05 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id 1B.06.04806.4C0457C5; Tue, 26 Feb 2019 13:36:04 +0000 (GMT) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20190226133604eucas1p260a569d2ac8721aa6f680973eb1ef0df~G7Wq4AVY83190631906eucas1p2j; Tue, 26 Feb 2019 13:36:04 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20190226133604eusmtrp1fb5a846963d4cb44d62f077d1c774831~G7WqpWEyE2514025140eusmtrp1V; Tue, 26 Feb 2019 13:36:04 +0000 (GMT) X-AuditID: cbfec7f5-34dff700000012c6-c5-5c7540c4898b Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 83.02.04128.3C0457C5; Tue, 26 Feb 2019 13:36:03 +0000 (GMT) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20190226133603eusmtip22d82c1b9bccc64d307e3e7047a372f23~G7WqFBbX81231312313eusmtip2o; Tue, 26 Feb 2019 13:36:03 +0000 (GMT) To: Maxime Coquelin , "Liu, Changpeng" , "dev@dpdk.org" Cc: "Stojaczyk, Dariusz" , "Bie, Tiwei" , "Wang, Zhihong" , Jason Wang From: Ilya Maximets Message-ID: Date: Tue, 26 Feb 2019 16:36:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsWy7djP87pHHEpjDHb2WVpc/PmV3eL97zWM Fu8+bWeyuNL+k91i2aXPTBbHOvewWGxt+M9ksfniJCYHDo9fC5ayeize85LJ4/2+q2wefVtW MQawRHHZpKTmZJalFunbJXBlnFv2mbXgn2LFpDW7GRsYV8p0MXJySAiYSMzc/Ji5i5GLQ0hg BaPEiuNPoJwvjBLndvWzQjifGSW+/9/FBtNyYO9yMFtIYDmjxI7lKRBFHxklOo5PYwFJCAt4 Sjy59A3MFhGoldh25SM7SBGzwCpGiT/LnrCDJNgEdCROrT7CCGLzCthJnF9wEcjm4GARUJV4 cSAQJCwqECFxuPcdVImgxMmZT8BmcgKVX7n8FOwIZgFxiaYvK1khbHmJ5q2zwV6QENjGLvF2 0VpmiKtdJKY8PsICYQtLvDq+hR3ClpE4PbkHKl4vcb/lJSNEcwejxPRD/5ggEvYSW16fYwc5 jllAU2L9Ln0QU0LAUaLxvBiEySdx460gxAl8EpO2TWeGCPNKdLQJQcxQkfh9cDnUMVISN999 Zp/AqDQLyWOzkDwzC8kzsxDWLmBkWcUonlpanJueWmycl1quV5yYW1yal66XnJ+7iRGYgk7/ O/51B+O+P0mHGAU4GJV4eH+YlsYIsSaWFVfmHmKU4GBWEuG9oQoU4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzlvN8CBaSCA9sSQ1OzW1ILUIJsvEwSnVwLhUZ2OGfdrDQ0FFNSZb+rmfzdRZ2TVz bXfs1QmR6vOUHzp8b7Fnn8scqqEsUmvHsyBr944bte81NFSStvf/mz9tl9/nu35rtgjMFQs/ 76cku+VysLlVafS7P2EFXFoCyzadb73x4dX2bs6ijZMFeYxf5Xz1uWQ55bna2uxPd1rYs7h3 KE3ZU6rEUpyRaKjFXFScCAC956B+PQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsVy+t/xe7qHHUpjDK4fsrC4+PMru8X732sY Ld592s5kcaX9J7vFskufmSyOde5hsdja8J/JYvPFSUwOHB6/Fixl9Vi85yWTx/t9V9k8+ras YgxgidKzKcovLUlVyMgvLrFVija0MNIztLTQMzKx1DM0No+1MjJV0rezSUnNySxLLdK3S9DL OLfsM2vBP8WKSWt2MzYwrpTpYuTkkBAwkTiwdzlbFyMXh5DAUkaJRW8mMUIkpCR+/LrACmEL S/y51gVV9J5RYv/0mUwgCWEBT4knl76xgNgiArUSC+5CTGIWWMUo0fRgJStERxOLxL6fC5lB qtgEdCROrT4CtoJXwE7i/IKLQDYHB4uAqsSLA4EgYVGBCImPT/cxQZQISpyc+QRsASdQ+ZXL T9lAbGYBdYk/8y4xQ9jiEk1fVrJC2PISzVtnM09gFJqFpH0WkpZZSFpmIWlZwMiyilEktbQ4 Nz232EivODG3uDQvXS85P3cTIzDyth37uWUHY9e74EOMAhyMSjy8P0xLY4RYE8uKK3MPMUpw MCuJ8N5QBQrxpiRWVqUW5ccXleakFh9iNAX6bSKzlGhyPjAp5JXEG5oamltYGpobmxubWSiJ 8543qIwSEkhPLEnNTk0tSC2C6WPi4JRqYPQpyuRYtdPpfdvLv5O8W/zC35is1lBIb5hka8r9 88/KQH/2BW2uuZcj93HVs+ycftb7BaNFz9XXURO3/31zW3H31GhL0eurFdse/FvufPPS1Oca +y3DLPddmDZ9ef8+PY+u6HNf13o82ext/TlE2yJ8Wznj80YGQ7kVEjzyP25HZe38yanWdlSJ pTgj0VCLuag4EQDQORg50gIAAA== X-CMS-MailID: 20190226133604eucas1p260a569d2ac8721aa6f680973eb1ef0df X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20190225132001eucas1p25c1e925b895b3ab36da0aca27110e15c X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190225132001eucas1p25c1e925b895b3ab36da0aca27110e15c References: <1551081095-14286-1-git-send-email-changpeng.liu@intel.com> <2c1b8abc-47a9-0d0b-5056-0092fc58e310@samsung.com> <4ba6108c-78b0-c7e6-f810-3faa13c7765e@samsung.com> <60245e11-ff68-133d-2577-8526c89e6264@samsung.com> Subject: Re: [dpdk-dev] vhost: add virtio configuration space access socket messages 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: Tue, 26 Feb 2019 13:36:07 -0000 On 26.02.2019 15:32, Maxime Coquelin wrote: > > > On 2/26/19 9:42 AM, Ilya Maximets wrote: >> On 26.02.2019 11:13, Liu, Changpeng wrote: >>> >>> >>>> -----Original Message----- >>>> From: Ilya Maximets [mailto:i.maximets@samsung.com] >>>> Sent: Tuesday, February 26, 2019 3:39 PM >>>> To: Liu, Changpeng ; dev@dpdk.org >>>> Cc: Stojaczyk, Dariusz ; >>>> maxime.coquelin@redhat.com; Bie, Tiwei ; Wang, >>>> Zhihong ; Jason Wang >>>> Subject: Re: vhost: add virtio configuration space access socket messages >>>> >>>> On 26.02.2019 10:01, Liu, Changpeng wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ilya Maximets [mailto:i.maximets@samsung.com] >>>>>> Sent: Monday, February 25, 2019 9:20 PM >>>>>> To: Liu, Changpeng ; dev@dpdk.org >>>>>> Cc: Stojaczyk, Dariusz ; >>>>>> maxime.coquelin@redhat.com; Bie, Tiwei ; Wang, >>>>>> Zhihong ; Jason Wang >>>>>> Subject: Re: vhost: add virtio configuration space access socket messages >>>>>> >>>>>> On 25.02.2019 10:51, Changpeng Liu wrote: >>>>>>> This patch adds new vhost user messages GET_CONFIG and SET_CONFIG >>>>>>> used to get/set virtio device's PCI configuration space. >>>>>> >>>>>> Beside the fact that some additional description and reasoning required, >>>>>> I do not see the usage of this feature. You're defining the flag >>>>>> VHOST_USER_PROTOCOL_F_CONFIG, but it's never used. So, none of dpdk >>>> vhost >>>>>> backends (vdpa, vhost-user) will use this feature. >>>>>> You, probably, missed adding it to VHOST_USER_PROTOCOL_FEATURES or >>>>>> VDPA_SUPPORTED_PROTOCOL_FEATURES. >>>>>> >>>>>>  From the other side, current implementation forces application to properly >>>>>> implement the get/set_config callbacks. Otherwise, receiving of the messages >>>>>> will result in RTE_VHOST_MSG_RESULT_ERR and subsequent vhost >>>>>> disconnection. >>>>>> This looks strange, because supported protocol features normally enabled by >>>>>> default. Am I misunderstood something ? >>>>> QEMU will not send the messages if VHOST_USER_PROTOCOL_F_CONFIG >>>> wasn't enabled. >>>> >>>> So, you're going to enable it only by explicit call to >>>> 'rte_vhost_driver_set_features' ? >>>> >>>> In this case I'm assuming that you're implementing your own vhost backend. >>>> But why you're not using 'dev->extern_ops' and corresponding 'pre_msg_handle' >>>> or 'post_msg_handle' to handle your GET/SET_CONFIG messages like it does >>>> 'vhost_crypto' backend ? >>> The patch was developed one year ago, while DPDK didn't have external ops. >> >> So, maybe it's time to reconsider the implementation. > > +1 > >>> The get_config/set_config was defined for all the virtio devices, so I think it makes >>> more sense adding here. >> >> VHOST_USER_*_CRYPTO_SESSION messages are defined for all the virtio devices >> too, however they makes sense for vhost_crypto backend only. These messages >> (GET/SET_CONFIG) makes sense only when callbacks (get/set_config) are >> implemented, so IMHO it's better to implement their handlers along with the >> callbacks, i.e. inside the implementation of your vhost backend. >> >> Maxime, Tiwei, what do you think ? > > I would prefer it to be implemented in SPDK directly as a pre_handler > callback, as I don't foresee a need for it for other backends, and it > would avoid breaking the API. > > It would imply fixing the beginning of vhost_user_msg_handler() to accept requests > VHOST_USER_MAX and add necessary check before doing > the debug logs. VHOST_USER_MAX is 31 and both new requests are defined in the same enum VhostUserRequest: VHOST_USER_GET_CONFIG = 24, VHOST_USER_SET_CONFIG = 25 I don't think that any change is needed here. > > With above change we would also be able to remove VHOST_CRYPTO requests > from vhost_user.c, Maybe you're looking at the different git HEAD ? I don't see any crypto related code in vhost_user.c. Only name definition in vhost_message_str. > and we could then work on moving vhost-net bits > out of this file too. > > Regards, > Maxime > > >