Date: Sun, 5 Sep 2004 23:14:21 -0700 From: Luigi Rizzo <luigi@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? (My pov) Message-ID: <20040905231421.B26501@xorpc.icir.org> In-Reply-To: <200409052137.i85LbV1V053075@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, Sep 05, 2004 at 02:37:31PM -0700 References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <200409052137.i85LbV1V053075@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 05, 2004 at 02:37:31PM -0700, Matthew Dillon wrote:
> Well, wait a second... are we talking about a lot of packets being
> discarded by the filter in 'normal' operation, or are we talking about
> an attack? Because if we are takling about an attack the LAST ethernet
...
Sure, in this thread we are talking of a performance hack for a
specific piece of hardware, which may be obsolete and poorly
performing, but is also one of the few widespread ones supporting
coax. Once upon a time, this hack was basically the only way to
make a coax bridge perform decently and not saturate the bus (ISA
or PCMCIA). Granted, these days maybe nobody uses coax anymore or
has a desire to upgrade these boxes.
If the existing code is broken (but please make a reasonable effort
to prove it, don't just hint things) or gets in the way because
e.g. it would complicate locking for everyone else, or because the
bridge_in_ptr() or BDG_ACTIVE() calls disappear from the API, then
i am all for the suggested change.
But if the suggested change is something in preparation for other
changes that may never see the light, then i'd rather just add a
comment/reminder in the relevant bridging file, and nuke the code
in if_ed.c and everywhere else when this becomes necessary. After
all the problem (alleged layering violation) is well understood,
and the offender (assuming this is the only one -- the way to check
would be rename bridge_in_ptr() and BDG_ACTIVE() to something
different and try a build of the kernel and modules) and the
trivial fix are known so postponing the change is not going
to harm anyone.
Speaking about layering violation -- sure, the above bridge thing
is a small one, but there are much worse (and more critical) offenders.
E.g. the device driver preferably should not know who is going to
consume its packets, and you are pointing the finger at the bridging
code -- but this applies to bpf as well, yet several drivers still
have explicit
if (ifp->if_bpf)
bpf_mtap(ifp, m_head);
or implicit
BPF_MTAP(ifp, m_head);
bpf hooks.
And another huge one is the support for delayed checksums, which
permeates the entire network stack and breaks bpf feeding it with
packets carrying invalid checksums.
I guess the above means "do what you like, just don't put an
'Approved by: luigi' line in the commit msg" :)
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040905231421.B26501>