On Thu, Apr 14, 2016 at 5:11 PM, KY Srinivasan <kys@xxxxxxxxxxxxx> wrote: > > >> -----Original Message----- >> From: Rustad, Mark D [mailto:mark.d.rustad@xxxxxxxxx] >> Sent: Thursday, April 14, 2016 5:07 PM >> To: KY Srinivasan <kys@xxxxxxxxxxxxx> >> Cc: David Miller <davem@xxxxxxxxxxxxx>; netdev >> <netdev@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; >> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; >> jasowang@xxxxxxxxxx; eli@xxxxxxxxxxxx; jackm@xxxxxxxxxxxx; >> yevgenyp@xxxxxxxxxxxx; Ronciak, John <john.ronciak@xxxxxxxxx>; intel- >> wired-lan@xxxxxxxxxxxxxxxxx >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts >> (Hyper-V) >> >> KY Srinivasan <kys@xxxxxxxxxxxxx> wrote: >> >> > >> > >> >> -----Original Message----- >> >> From: Rustad, Mark D [mailto:mark.d.rustad@xxxxxxxxx] >> >> Sent: Thursday, April 14, 2016 4:01 PM >> >> To: KY Srinivasan <kys@xxxxxxxxxxxxx> >> >> Cc: David Miller <davem@xxxxxxxxxxxxx>; netdev >> >> <netdev@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; >> >> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; >> >> jasowang@xxxxxxxxxx; eli@xxxxxxxxxxxx; jackm@xxxxxxxxxxxx; >> >> yevgenyp@xxxxxxxxxxxx; Ronciak, John <john.ronciak@xxxxxxxxx>; >> intel- >> >> wired-lan@xxxxxxxxxxxxxxxxx >> >> Subject: Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts >> >> (Hyper-V) >> >> >> >> Some comments below: >> > >> > Mark, >> > >> > Thank you for the comments. I will address them and repost the patches. >> > >> > Regards, >> > >> > K. Y >> >> Please look closely at Alex's comments. I think they are much more >> important. > > I am looking at Alex's comments as I am writing this. > On additional thought that just occurred to me after looking over the other patches you submitted for the hv_netvsc is that you might just stub out the multicast, unicast, and vfta configuration calls for the hyperV interface since all that stuff should be handled by the other link in the bond anyway. Then you should be able to mostly contain all the changes other than the device IDs to the vf.c file which is really how this kind of change should work anyway. Also I was wondering. Since HyperV is using a proprietary device ID anyway do you really need the calls like the one below?: + if (x86_hyper == &x86_hyper_ms_hyperv) { If we can just identify HyperV via the device Id then we could drop the x86 arch specific bits and instead just build for all cases. - Alex _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
