在 2021/4/13 下午12:28, Yongji Xie 写道:
On Tue, Apr 13, 2021 at 11:35 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
在 2021/4/12 下午5:59, Yongji Xie 写道:
On Mon, Apr 12, 2021 at 5:37 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
在 2021/4/12 下午4:02, Yongji Xie 写道:
On Mon, Apr 12, 2021 at 3:16 PM Jason Wang <jasowang@xxxxxxxxxx> 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,
Yongji
Right, I see.
So I'm fine with current approach.
Thanks
