Thank you so much for the detailed explanation! On Wed, Sep 4, 2019 at 10:56 PM Jason Wang <jasowang@xxxxxxxxxx> wrote: > Let me explain: > > - I'm not suggesting to use vhost_net since it can only deal with > userspace virtio rings. > - I suggest to introduce netdev that has vringh vring assoticated. > Vringh was designed to deal with virtio ring located at different types > of memory. It supports userspace vring and kernel vring currently, but > it should not be too hard to add support for e.g endpoint device that > requires DMA or whatever other method to access the vring. So it was by > design to talk directly with e.g kernel virtio device. > - In your case, you can read vring address from virtio config space > through endpoint framework and then create vringh. It's as simple as: > creating a netdev, read vring address, and initialize vringh. Then you > can use vringh helper to get iov and build skb etc (similar to caif_virti= > o). You are right. It's easy to set up corresponding vringh's. > The differences is. > - Complexity: In your proposal, there will be two virtio devices and 4 > virtqueues. It means you need to prepare two sets of features, config > ops etc. And dealing with inconsistent feature will be a pain. It may > work for simple case like a virtio-net device with only _F_MAC, but it > would be hard to be expanded. If we decide to go for vringh, there will > be a single virtio device and 2 virtqueues. In the endpoint part, it > will be 2 vringh vring (which is actually point the same virtqueue from > Host side) and a normal network device. There's no need for dealing with > inconsistency, since vringh basically sever as a a device > implementation, the feature negotiation is just between device (network > device with vringh) and driver (virtito-pci) from the view of Linux > running on the PCI Host. > - Maintainability: A third path for dealing virtio ring. We've already > had vhost and vringh, a third path will add a lot of overhead when > trying to maintaining them. My proposal will try to reuse vringh, > there's no need a new path. I also agree with this part. This is the more sustainable way to go also because vringh is actively maintained together with virtio. > not that hard as you imagine to have a new type of netdev, I suggest to > take a look at how caif_virtio is done, it would be helpful. This is the part where I had misunderstanding about. I would read how caif_virtio use vringh to for networking stuff. Again thank you for spending so much time and thought! Haotian
