Date: Thu, 22 May 2008 13:42:53 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Niki Denev <nike_d@cytexbg.com> Cc: Max Laier <max@love2party.net>, freebsd-net@freebsd.org Subject: Re: lagg0.2 style vlans on lagg(4) interface Message-ID: <48356A4D.2050404@FreeBSD.org> In-Reply-To: <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com> References: <2e77fc10805211031n6c42ffd2u3dee28164094b83b@mail.gmail.com> <200805212332.13993.max@love2party.net> <2e77fc10805211514q59dd0eadkac2edce50d6c22f7@mail.gmail.com> <200805220041.24096.max@love2party.net> <2e77fc10805212057y7cbeca00kd096a7b090413616@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, It looks like this patch will cause gratuitous ARP to be queued even when the interface is not IFF_UP, is this intentional? Niki Denev wrote: > > I think arp_gratuit() needs a better name. > arp_announce() ? > Is if_ethersubr.c:ether_ifattach() good place to register the EVENT hook? > ARP is also used by FDDI and IEEE 802.5, as well as anything which emulates this. Taking the call to arp_ifinit() out of if_setlladdr() is likely to break this code. > And if yes, what would be the best way to handle failure to register > the hook, as the function is void? > > Should I worry about that, or just print a warning message and continue? > I see the C++-style comments - perhaps someone who knows event handlers better than I can comment, I believe it's using one of the shared kernel malloc pools with M_WAIT. It looks like this won't run afoul of locking, but it is a change to a fairly central path which needs to be considered carefully as it affects consumers other than Ethernet drivers. cheers BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48356A4D.2050404>