Date: Fri, 3 Oct 2014 14:04:05 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Hariprasad S <hariprasad@chelsio.com> Subject: Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic Message-ID: <20141003100405.GB73266@glebius.int.ru> In-Reply-To: <542E71D3.6000500@FreeBSD.org> References: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> <542E71D3.6000500@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 03, 2014 at 01:52:19PM +0400, Alexander V. Chernikov wrote: A> On 03.10.2014 04:40, Hariprasad S wrote: A> > HI, A> > A> > Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. A> > Kernel used: FreeBSD HEAD r272051 A> > A> > Is anyone aware of this issue? A> Yes. What is happening here: A> We acquire lagg WLOCK to set new link layer address (due to "master" A> interface change). A> We propagate this change to vlans on top if lagg (or to lagg itself). A> Then we need to send gratuitous ARP for each UP interface, so we have to A> acquire lagg read lock to actually transmit this frame.. A> A> We can fix this particular case, but I think it should be done more A> generic way via introducing one or more netisr(9) slow path queues A> and making sure "every" locally-originated packet is queued instead of A> being transmitted directly. A> A> Previous proposal: A> https://lists.freebsd.org/pipermail/freebsd-hackers/2014-January/044121.html A> It looks like we should return to the discussion. I agree with Alexander here. However, he is quite aggresive on the question which packets should qualify for slow path :) Well, this is a matter to discuss, but the overall mechanism is needed. And gratuitous ARPs are definitely qualified for that. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141003100405.GB73266>