Hi, I wanted to follow up on my previous message regarding the development of a vhost vDPA host driver for crypto/virtio. We have proposed creating a driver/common/virtio/ directory to hold common implementations for both net and crypto functionalities. This approach aims to help in fixing common issues and extending virtio functionalities efficiently.
As we plan to include this feature in DPDK 25.03, we would like to conclude on the implementation direction soon. We would greatly appreciate your valuable feedback or any suggestions on this proposal. Thank you! Thanks, Gowrishankar > Hi, > We are adding support for vDPA user backend for virtio-crypto PMD in DPDK. > We have come up with functional changes which is similar to the support > available in net: > > commit 6b901437056eed3ed7c9932c333ba24ac5be116f > > net/virtio: introduce vhost-vDPA backend > vhost-vDPA is a new virtio backend type introduced by vDPA kernel > framework, which provides abstraction to the vDPA devices and > exposes an unified control interface through a char dev. > > Our current development reuses some code from net/virtio/virtio_user/, and > we realize that we could keep a few things in common between net and > crypto, such as: > > -> vhost_vdpa.c (and its header file) from net/virtio/virtio_user/: > Except for VHOST_VDPA_GET_DEVICE_ID and enabling queue pairs, > virtio_user_backend_ops can be reused. > -> virtio_user_dev.c (and its header file) from net/virtio/virtio_user/: > virtio_user_dev_init and its capabilities differ. > -> virtio_cvq.c (and its header file) from net/virtio/: > There is a difference in the usage of the first and last descriptors for > the virtio > header and status (net vs. crypto). > > We need to standardize these codes to ensure they work universally. > Therefore, we propose creating a driver/common/virtio/ directory to house > them. This approach will help address common issues and extend Virtio > functionalities shared between crypto and net. For example, the crypto PMD > can benefit from packed ring support. We welcome your valuable feedback > and any suggestions. > > Thanks, > Gowrishankar > -- > 2.37.1
