Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

[Alexander Duyck]

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