Date: Mon, 20 Feb 2012 18:21:34 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: net@freebsd.org, Brooks Davis <brooks@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Abstracting struct ifnet Message-ID: <CACVs6=_kTVC7tnsPJqgRq3VtUaSefkunVU8JetTdsXjGCmUT7A@mail.gmail.com> In-Reply-To: <CAJ-Vmoni1DHpxet08=JWSDGLFBP7MHO4-WDBLwX9vGxibR=EDA@mail.gmail.com> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <CAJ-Vmoni1DHpxet08=JWSDGLFBP7MHO4-WDBLwX9vGxibR=EDA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 20, 2012 at 16:37, Adrian Chadd <adrian@freebsd.org> wrote: > On 20 February 2012 16:15, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > >>> The concept seems fine to me and I like that it might simplify future >>> API changes. =C2=A0Have you verified that if_get_*() accessors don't ad= d >>> significant overhead? >> >> the vast majority of these fields are only accessed in the control path, >> not on each packet, so there isn't really a performance issue. Besides >> they can be trivially implemted as macros or inline functions. > > I doubt Juniper need _binary_ level compatibility. So we could get > away with inline methods. > > This sort of thing just makes source level compatibility a lot easier. It's not just about Juniper, though, it's about us, and how much this buys us. Using inlines buys us some source compatibility and the ability to add some invariants, but is no different to macros in terms of KBI within a version of FreeBSD, or between versions. We can't make ifnet opaque with inlines. Adding a member to ifnet which is opaque[*] and which has the fields most likely to change in size, order, existence, etc., and leaving a few that are needed in the fast path and will be used by macros/inlines is probably where we should end up. *: Obviously ifnet should be a value member of the opaque type, and the ifnet should include a pointer to the opaque type, or something like that, since you can't make an opaque struct a value member, which is probably obvious, but I wanted to be clearish.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=_kTVC7tnsPJqgRq3VtUaSefkunVU8JetTdsXjGCmUT7A>