On Fri, Feb 23, 2018 at 3:59 PM, Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, 22 Feb 2018 13:30:12 -0800 > Alexander Duyck <alexander.duyck@xxxxxxxxx> wrote: > >> > Again, I undertand your motivation. Yet I don't like your solution. >> > But if the decision is made to do this in-driver bonding. I would like >> > to see it baing done some generic way: >> > 1) share the same "in-driver bonding core" code with netvsc >> > put to net/core. >> > 2) the "in-driver bonding core" will strictly limit the functionality, >> > like active-backup mode only, one vf, one backup, vf netdev type >> > check (so noone could enslave a tap or anything else) >> > If user would need something more, he should employ team/bond. > > Sharing would be good, but netvsc world would really like to only have > one visible network device. Other than the netdev count are there any other issues we need to be thinking about? If I am not mistaken you netvsc doesn't put any broadcast/multicast filters on the VF. If we ended up doing that in order to support the virtio based solution would that cause any issues? I just realized we had overlooked dealing with multicast in our current solution so we will probably be looking at syncing the multicast list like what occurs in netvsc, however we will need to do it for both the VF and the virtio interfaces. Thanks. - Alex _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
