On 3/4/2018 10:50 AM, Jiri Pirko wrote:
Sun, Mar 04, 2018 at 07:24:12PM CET, alexander.du...@gmail.com wrote:
On Sat, Mar 3, 2018 at 11:13 PM, Jiri Pirko <j...@resnulli.us> wrote:
Sun, Mar 04, 2018 at 01:26:53AM CET, alexander.du...@gmail.com wrote:
On Sat, Mar 3, 2018 at 1:25 PM, Jiri Pirko <j...@resnulli.us> wrote:
Sat, Mar 03, 2018 at 07:04:57PM CET, alexander.du...@gmail.com wrote:
On Sat, Mar 3, 2018 at 3:31 AM, Jiri Pirko <j...@resnulli.us> wrote:
Fri, Mar 02, 2018 at 08:42:47PM CET, m...@redhat.com wrote:
On Fri, Mar 02, 2018 at 05:20:17PM +0100, Jiri Pirko wrote:
Yeah, this code essentially calls out the "shareable" code with a
comment at the start and end of the section what defines the
virtio_bypass functionality. It would just be a matter of mostly
cutting and pasting to put it into a separate driver module.
Please put it there and unite the use of it with netvsc.
Surely, adding this to other drivers (e.g. might this be handy for xen
too?) can be left for a separate patchset. Let's get one device merged
first.
Why? Let's do the generic infra alongside with the driver. I see no good
reason to rush into merging driver and only later, if ever, to convert
it to generic solution. On contrary. That would lead into multiple
approaches and different behavious in multiple drivers. That is plain
wrong.
If nothing else it doesn't hurt to do this in one driver in a generic
way, and once it has been proven to address all the needs of that one
driver we can then start moving other drivers to it. The current
solution is quite generic, that was my contribution to this patch set
as I didn't like how invasive it was being to virtio and thought it
would be best to keep this as minimally invasive as possible.
My preference would be to give this a release or two in virtio to
mature before we start pushing it onto other drivers. It shouldn't
take much to cut/paste this into a new driver file once we decide it
is time to start extending it out to other drivers.
I'm not talking about cut/paste and in fact that is what I'm worried
about. I'm talking about common code in net/core/ or somewhere that
would take care of this in-driver bonding. Each driver, like virtio_net,
netvsc would just register some ops to it and the core would do all
logic. I believe it is essential take this approach from the start.
Sorry, I didn't mean cut/paste into another driver, I meant to make it
a driver of its own. My thought was to eventually create a shared/core
driver module that is then used by the other drivers.
My concern right now is that Stephen has indicated he doesn't want
this approach taken with netvsc, and most of the community doesn't
IIUC, he only does not like the extra netdev. Is there anything else?
Nope that is pretty much it. It doesn't seem like a big deal for
virtio, but for netvsc it is significant since they don't have any
"backup" bit feature differentiation, so they would likely be stuck
with 2 netdevs even in their basic setup.
Okay. If that is a strict "no-go" for netvsc, this should be
just a flag passed down to the in-driver bond code.
This results in a 3 driver model (virtio/netvsc, vf & bypass) with 2 netdevs
created when bypass is based on netvsc and 3 netdevs created when the bypass
is based on virtio_net.
Unless we agree on a common netdev model between netvsc and virtio_net,
i am not sure if it is useful to commonize the code into a separate driver.
-Sridhar
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
