> -----Original Message----- > From: Florian Fainelli [mailto:f.fainelli@xxxxxxxxx] > Sent: Monday, August 11, 2014 11:52 AM > > I suppose you meant the below logic: > > if (refresh) { > > rtnl_lock(); > > netif_carrier_off(net); > > netif_carrier_on(net); > > rtnl_unlock(); > > } > > > > We have discussed this in the previous mails of this thread itself: > > e.g., http://marc.info/?l=linux-driver-devel&m=140593811715975&w=2 > > > > Unluckily this logic doesn't work because the user-space daemons > > like ifplugd, usually don't renew the DHCP immediately as long as they > > receive a link-down message: they usually wait for some seconds and if > > they find the link becomes up soon, they won't trigger renew operations. > > (I guess this behavior can be somewhat reasonable: maybe the daemons > > try to not trigger DHCP renew on temporary link instability) > > Is that such a big deal? If you know you spend much of your time in > ifplugd, why not use something different that triggers a DHCP renewal > faster, or fix ifplugd? Hi Florian, Thanks for the comment! Yes, we can fix ifplugd and ALL other equivalent daemons, but that would need much more efforts, so I was trying to add a workaround in the kernel driver -- now I've realized this is not a good solution. :-) > > If we use this logic in the kernel space, we'll have to "fix" the user-space > > daemons, like ifplugd, systemd-networkd...,etc. > > You mean the opposite here don't you? If you put that logic in kernel > space you don't have to fix the userland. I think we'll have to fix the userland or customize the userland by passing proper parameters(if there is any) to the userland daemons(when they run in a hyper-v guest) if we use the below logic in the driver: if (refresh) { rtnl_lock(); netif_carrier_off(net); netif_carrier_on(net); rtnl_unlock(); } e.g., as Bill told in another mail, ifplugd has --delay-down. > > I'm not sure our attempt to "fix" the daemons can be easily accepted. > > BTW, by CPUID, an application has a reliable way to determine if it's > > running on hyper-v on not. Maybe we can "fix" the behavior of the > > daemons when they run on hyper-v? > > That is not acceptable as well, why would an user-space application > would have to care that much whether it runs on hyper-v or a physical > host? Not to mention that anytime someone develops a similar but new > application they would have to become aware of such platform and its > "specicities". Ok, I understood. > > BTW2, according to my limited experience, I doubt other VMMs can > > handle this auto-DHCP-renew-in-guest issue properly. > > > > That was why Yue's patch wanted to add a SLEEP(10s) between the > > link-down and link-up events and hoped this could be an acceptable > > fix(while it turned out not, obviously), though we admit it's not so good > > to add such a magic number "10s" in a kernel driver. > > > > Please point it out if I missed or misunderstand something. > > I think this is just an integration issue that you are having, and I > would not be focusing on any particular user-space implementation, but > rather put something in the driver that is sensible, just like what was > suggested before: toggling the carrier state. OK, let me send a netif_carrier_off()/on() patch after I verify the daemons can work with proper parameters specified. Thanks, -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
