> Subject: Re: [Patch v5 0/3] Introduce a driver to support host accelerated access > to Microsoft Azure Blob for Azure VM > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > On Fri, Oct 08, 2021 at 01:11:02PM +0200, Vitaly Kuznetsov wrote: > >> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > >> > >> ... > >> > > >> > Not to mention the whole crazy idea of "let's implement our REST > >> > api that used to go over a network connection over an ioctl instead!" > >> > That's the main problem that you need to push back on here. > >> > > >> > What is forcing you to put all of this into the kernel in the first > >> > place? What's wrong with the userspace network connection/protocol > >> > that you have today? > >> > > >> > Does this mean that we now have to implement all REST apis that > >> > people dream up as ioctl interfaces over a hyperv transport? That > >> > would be insane. > >> > >> As far as I understand, the purpose of the driver is to replace a "slow" > >> network connection to API endpoint with a "fast" transport over > >> Vmbus. > > > > Given that the network connection is already over vmbus, how is this > > "slow" today? I have yet to see any benchmark numbers anywhere :( > > > >> So what if instead of implementing this new driver we just use > >> Hyper-V Vsock and move API endpoint to the host? > > > > What is running on the host in the hypervisor that is supposed to be > > handling these requests? Isn't that really on some other guest? > > > > Long, > > would it be possible to draw a simple picture for us describing the backend flow > of the feature, both with network connection and with this new driver? We're > struggling to understand which particular bottleneck the driver is trying to > eliminate. Thank you for this great suggestion. I'm preparing some diagrams for describing the problem. I will be sending them soon. Thanks, Long > > -- > Vitaly
