Jason Wang
2021-Apr-14 08:18 UTC
[PATCH v6 09/10] vduse: Introduce VDUSE - vDPA Device in Userspace
? 2021/4/13 ??12:28, Yongji Xie ??:> On Tue, Apr 13, 2021 at 11:35 AM Jason Wang <jasowang at redhat.com> wrote: >> >> ? 2021/4/12 ??5:59, Yongji Xie ??: >>> On Mon, Apr 12, 2021 at 5:37 PM Jason Wang <jasowang at redhat.com> wrote: >>>> ? 2021/4/12 ??4:02, Yongji Xie ??: >>>>> On Mon, Apr 12, 2021 at 3:16 PM Jason Wang <jasowang at redhat.com> wrote: >>>>>> ? 2021/4/9 ??4:02, Yongji Xie ??: >>>>>>>>>>> +}; >>>>>>>>>>> + >>>>>>>>>>> +struct vduse_dev_config_data { >>>>>>>>>>> + __u32 offset; /* offset from the beginning of config space */ >>>>>>>>>>> + __u32 len; /* the length to read/write */ >>>>>>>>>>> + __u8 data[VDUSE_CONFIG_DATA_LEN]; /* data buffer used to read/write */ >>>>>>>>>> Note that since VDUSE_CONFIG_DATA_LEN is part of uAPI it means we can >>>>>>>>>> not change it in the future. >>>>>>>>>> >>>>>>>>>> So this might suffcient for future features or all type of virtio devices. >>>>>>>>>> >>>>>>>>> Do you mean 256 is no enough here? >>>>>>>> Yes. >>>>>>>> >>>>>>> But this request will be submitted multiple times if config lengh is >>>>>>> larger than 256. So do you think whether we need to extent the size to >>>>>>> 512 or larger? >>>>>> So I think you'd better either: >>>>>> >>>>>> 1) document the limitation (256) in somewhere, (better both uapi and doc) >>>>>> >>>>> But the VDUSE_CONFIG_DATA_LEN doesn't mean the limitation of >>>>> configuration space. It only means the maximum size of one data >>>>> transfer for configuration space. Do you mean document this? >>>> Yes, and another thing is that since you're using >>>> data[VDUSE_CONFIG_DATA_LEN] in the uapi, it implies the length is always >>>> 256 which seems not good and not what the code is wrote. >>>> >>> How about renaming VDUSE_CONFIG_DATA_LEN to VDUSE_MAX_TRANSFER_LEN? >>> >>> Thanks, >>> Yongji >> >> So a question is the reason to have a limitation of this in the uAPI? >> Note that in vhost-vdpa we don't have such: >> >> struct vhost_vdpa_config { >> __u32 off; >> __u32 len; >> __u8 buf[0]; >> }; >> > If so, we need to call read()/write() multiple times each time > receiving/sending one request or response in userspace and kernel. For > example, > > 1. read and check request/response type > 2. read and check config length if type is VDUSE_SET_CONFIG or VDUSE_GET_CONFIG > 3. read the payload > > Not sure if it's worth it. > > Thanks, > YongjiRight, I see. So I'm fine with current approach. Thanks>