Date: Mon, 15 Sep 2014 10:14:54 -0600 From: Alan Somers <asomers@freebsd.org> To: "Alexander V. Chernikov" <melifaro@freebsd.org> Cc: "net@freebsd.org" <net@freebsd.org> Subject: Re: if_lagg(4) accounting changes Message-ID: <CAOtMX2jWW%2Bi3BWD-eZa%2B3nQXVsg-f11aq9R%2BwUf3j1PEXCnFiA@mail.gmail.com> In-Reply-To: <5414D10E.7020000@FreeBSD.org> References: <5414D10E.7020000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 13, 2014 at 5:19 PM, Alexander V. Chernikov <melifaro@freebsd.org> wrote: > Hello list. > > I'd like to commit some changes to lagg counters which might be worth > discussion. > > Diff is available at https://reviews.freebsd.org/D781 > Quoting its summary: > > > While counting packets using per-cpu counters might not introduce > any significant overhead at current rates, we do not need to > do such accounting at all. > > lagg in general is pure control-plane interface, its action on > receive should be just to change packet src if pointer. > Its action on transmit should be just selecting output interface > based on flowid. > It should not generate any errors on its own. > > In fact, RX lagg path can be skipped by setting correct ifp inside > NIC driver. TX path should be handled by generic multipath L2 nexthops > inside routing code. > > This is first step for implementing this scenario. > One side effect is that we're now collecting all counters (including > errors) from underlying interfaces. Generally most networking HW vendors > implement this behavior for their equipment and this is really the > reasonable thing to do. Sounds interesting. I'll give it a thorough review soon, but probably not today. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jWW%2Bi3BWD-eZa%2B3nQXVsg-f11aq9R%2BwUf3j1PEXCnFiA>