Re: IFNAMSIZ/IF_NAMESIZE change proposal
On 9/14/13 9:21 AM, "Warner Losh" wrote: > >On Sep 14, 2013, at 2:44 AM, Anuranjan Shukla wrote: >> At Juniper Networks, interface name size was needed to be longer than >>what FreeBSD has. We're trying to reduce our local changes to FreeBSD to >>allow us an easier time upgrading to newer FreeBSD releases, and support >>the modularization of the network stack we'd proposed earlier. I'm >>sending this out to propose changing IFNAMSIZ from 16 to 60 (this is >>the size we use) in FreeBSD. We don't see any downside (other than >>increasing the ifreq structure size for one) to doing this, as allowing >>longer interface names can be handy for vendors. I'd like to hear if >>there's a strong objection to this. If not, we'd like to get this into >>to the FreeBSD codebase. Any thoughts/objections highly appreciated. > >56 or 64 would be better for alignment, wouldn't it? Yes, but then we need to change Junos' definition to match FreeBSD's and we're not sure yet if that's at all possible. Hence the suggestion to use what we have at Juniper. If a "nicer" length is preferred, then we'll see about making that happen. Thoughts? -- Marcel Moolenaar marc...@juniper.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Abstracting struct ifnet
All,
Juniper is in the final phases of creating a clean separation
between FreeBSD and Junos, so as to make upgrades of FreeBSD
easier. This also allows Juniper to track -current and be more
active FreeBSD contributors.
To that end, we have a short-term and hopefully short-lived
problem to solve, which is the ability to use FreeBSD's network
drivers against the Junos network stack. As some may know, the
Junos network stack has split up struct ifnet into a physical
and logical component, called ifdev and iflogical.
We've tried a few approaches to bridge the gap between ifnet
on the one hand and ifdev and iflogical on the other and found
that abstracting ifnet and using accessor functions is the
best way to allow us to use FreeBSD drivers with the Junos
network stack, while retaining the ability to use them with
the FreeBSD stack.
FreeBSD is also looking at breaking up ifnet and with that in
mind, I was wondering if there would be any resistance to
changing network drivers to use accessor functions or macros
instead of direct pointer dereferences?
For example, do something like:
Index: if_fxp.c
===
--- if_fxp.c(revision 231178)
+++ if_fxp.c(working copy)
@@ -823,13 +823,14 @@
}
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
- ifp->if_init = fxp_init;
- ifp->if_softc = sc;
- ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
- ifp->if_ioctl = fxp_ioctl;
- ifp->if_start = fxp_start;
+ if_set_init(ifp, fxp_init);
+ if_set_softc(ifp, sc);
+ if_set_flags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST, 0);
+ if_set_ioctl(ifp, fxp_ioctl);
+ if_set_start(ifp, fxp_start);
- ifp->if_capabilities = ifp->if_capenable = 0;
+ if_set_capabilities(ifp, 0);
+ if_set_capenable(ifp, 0);
/* Enable checksum offload/TSO for 82550 or better chips */
if (sc->flags & FXP_FLAG_EXT_RFA) {
Such a scheme, while initially touching a lot of driver,
would make it easier to break up ifnet *and* also make it
easier to hide ABI/API changes from driver vendors (esp.
when the accessor functions are non-inlined functions and
not macros or inlines). This is particularly useful for
Juniper, where we have worked towards network stacks as
(pre-)loadable modules so as to help with migration and
validation.
Thoughts, feedback and suggestion are welcome,
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Abstracting struct ifnet
On Feb 17, 2012, at 5:53 AM, Gleb Smirnoff wrote: > M> Thoughts, feedback and suggestion are welcome, > > Is it possible to make the structure the driver points to opaque? > > Once made, that would allow us to hack on the ifnet (or on its > successor - iflogical) more aggressively without breaking ABI/API. Yes, that's the idea. Backward compatibility kinda conflicts with making struct ifnet entirely abstract, but I don't see that as a problem without solution. Only as a problem for which an acceptable solution must be found. For example: you can introduce a define that either old or new drivers use to indicate whether they need full visibility or whether an abstract type works. This then drives what is defined/declared and how it's defined/declared. -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Abstracting struct ifnet
On Feb 17, 2012, at 12:23 AM, Luigi Rizzo wrote: >> >> Thoughts, feedback and suggestion are welcome, > > I do like the idea, but the amount of changes will be massive > (see below). The thing that worries me the most is that it > will introduce huge changes between different releases, unless > we backport the accessors (while keeping the underlying struct ifnet > frozen so we preserve the kernel ABI). Hi Luigi, That's a good point. When we have something to work with on -current and ideally with only a few drivers changed, we not only have a hybrid approach in -current, which allows us to stage the work, we also have the inherent support for backward compatibility. This then can be put in 9-stable to allow for "the new network" drivers to be used in a 9-stable code base as well. As for the amount of change: yes, it's large. But I think it's a good investment and an enabler for structural ifnet rework. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Abstracting struct ifnet
On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote: > On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: >> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: >>> Is the target though _binary_ compatibility? Just having a blessed >>> method of doing accessor method things will buy more source >>> flexibility. The KBI can stay the same in the default case and IMHO >>> this kind of thing gives developers more power to do smart invariant >>> and debugging things. >> >> KBI compatibility requires very little discipline and makes loadable >> modules for network drivers much less hellish. Inlines, macros and >> full visibility of ifnet in -current may be useful, but unless there's >> a performance reason for doing so, retaining KBI compatibility *and* >> the ability to merge ifnet changes to -stable sounds pretty nice to >> me. *snip* > You could take a look how mutexes or vm_page_locks are handled, > giving inlines for kernel proper and stable KBI for modules. A stable KBI is what we'll be aiming for at Juniper. We're working towards a kernel proper without any networking, the FreeBSD network stack as a module, the Juniper network stack as a module and H/W network drivers as modules. The network drivers and how they talk to the network stack is the big piece we still had to flesh out. Dynamic loading and unloading of network stack modules is not a goal, but we do want to be able to pre-load the network stack that we want to use and not have to worry about matching the H/W network drivers with the stack of choice. Inlines for the kernel proper and a stable KBI for modules seems to match everyone's objectives/concerns. We'll definitely take a look at the mutexes and vm_page_locks. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposal for changes to network device drivers and network stack (RFC)
On Aug 28, 2012, at 10:24 AM, PseudoCylon wrote: > Wouldn't using prepossessor macro or hooking be more flexible? (Could > support multiple functionality.) Macros make it impossible to treat ifnet as an opaque type. As such, it won't be possible to havr a single pre-compiled driver that can work with different network stacks. It's definitely been on our minds to make it possible to use macros for performance reasons when ABI stability is not a concern, but wanted to focus on ABI stability first. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposal for changes to network device drivers and network stack (RFC)
On Sep 5, 2012, at 1:16 PM, George Neville-Neil wrote: > One more note. Can you break the patches down into more bite sized pieces? > They're hard > to review as is. Following up finally. Let's focus on the device driver interface. I renamed the interface implementation from mumble_ddi.h to if_device.[ch] and put a diff here: http://people.freebsd.org/~marcel/Juniper/if_device.diff To see how it's used and/or how it changes a device driver, look at a diff to if_em.c here: http://people.freebsd.org/~marcel/Juniper/if_em.diff Some notes: 1. Yes, there needs a license at the top. It's 2-clause BSD 2. The function pointers are macros right now. I think it's better to have an ops structure and a single function to set the ops than a bunch of accessors to set functions. 3. The code needs to be tidied up. What I'd like to see is a discussion on the functions themselves. They're the result of looking at a single driver (or maybe 2 drivers), and as such may not be perfectly generic or logical. As said before: we'd like to focus on an ABI-stable interface, but a one based on macros should also be possible. Sorry for the delay, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netstat output on a recent head
> On Feb 25, 2015, at 8:42 AM, Marcel Moolenaar wrote: > > >> On Feb 24, 2015, at 3:00 PM, Navdeep Parhar wrote: >> >> I see a lot of literal "%s" in netstat's output on head. This on a >> freshly built system from today.. >> >> >> # netstat -hdw 1 > > Oops. > > The bug is with -h. If you remove -h you get the expected output > (except not humanized). I’ll fix it today. Fixed with revision 279288. Sorry for the breakage. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: netstat output on a recent head
> On Feb 24, 2015, at 3:00 PM, Navdeep Parhar wrote: > > I see a lot of literal "%s" in netstat's output on head. This on a > freshly built system from today.. > > > # netstat -hdw 1 Oops. The bug is with -h. If you remove -h you get the expected output (except not humanized). I’ll fix it today. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEAD UP: non-MPSAFE network drivers to be disabled
On May 27, 2008, at 1:49 PM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) yep :-) we need to decide if the aim is to support just serial ports or any 'tty'. Agreed. ucom(4) is in scope... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-ia64->freebsd-net Responsible-Changed-By: marcel Responsible-Changed-When: Wed May 25 02:27:47 GMT 2005 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
The following reply was made to PR ia64/81284; it has been noted by GNATS. From: Marcel Moolenaar <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 Date: Tue, 24 May 2005 19:45:37 -0700 The problem is not specific to ia64. Any 64-bit platform with strong alignment will have a misalignment panic. Note that pf_addrcpy() is called from pf_test() in the failing case. (pf.c, line 6349) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: marcel Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 Responsible-Changed-Why: Move to a more pf-focussed responsible party. http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote: On Mon, Jun 13, 2005 at 09:23:50PM +, Marcel Moolenaar wrote: Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: marcel Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 Responsible-Changed-Why: Move to a more pf-focussed responsible party. http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 If I understand the problem correctly, there is an underlying network-generic question I'd like to ask here. When a function in the kernel gets passed a struct ip pointer, can it assume that the struct ip object pointed to is properly aligned? Or should it assume that this is not the case, and extract members more carefully? That entirely depends. If a struct ip pointer is constructed without any form of casting, then one can assume that alignment is guaranteed. The compiler guarantees to do so, except of course in this case: the structure is defined as a packed structure. We, as the developers, have told the compiler to *NOT* guarantee alignment of fields. We're on our own and we miserably fail being on our own. We can fix the access in pf of course, but if other functions rightfully count on struct ip objects being properly aligned, this might simply crash outside of pf, too. True. But since struct ip is defined as packed, nobody can assume proper alignment of multi-byte fields and all code needs to be fixed if such assumptions are being made. In short, is the problem that bridge doesn't properly align the struct ip object (which I can try to fix, too), or that pf assumes that such objects should be aligned? pf(4) falsely assumes alignment. If I'm way off, and proper alignment of struct ip objects does not guarantee proper alignment of the ip_src/dst members as 32-bit unsigneds, please explain. You're not way off. It's just that we tried to outsmart ourselves by telling the compiler that it should not enforce proper alignment of fields in struct ip. If ia64 is different from other 64-bit architectures (of which I only know amd64, sparc64 and alpha), please explain what alignment rules there are for u_int32_t. ia64 is not different in this respect. That's why the bug is not specific to ia64. Note that amd64 may not be a perfect reference in this case because it's too much like i386, which does unaligned loads and stores. FYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64
On Jun 15, 2005, at 3:34 PM, Daniel Hartmeier wrote: On Wed, Jun 15, 2005 at 02:23:24PM -0700, Marcel Moolenaar wrote: That entirely depends. If a struct ip pointer is constructed without any form of casting, then one can assume that alignment is guaranteed. The compiler guarantees to do so, except of course in this case: the structure is defined as a packed structure. We, as the developers, have told the compiler to *NOT* guarantee alignment of fields. We're on our own and we miserably fail being on our own. 'packed', as I understand it, prohibits the compiler from inserting any padding anywhere in the struct. That is, it guarantees that the total size of a struct object equals the sum of the sizes of its members. As a consequence, individual members can't be aligned properly if that would require padding in front of them. The compiler can (and must?) still align the first member, i.e. the beginning of the struct object, though, no? No, it can't guarantee alignment of the first field and consequently will not bother trying. The best way to picture this is with an array. Alignment guarantees has to come from the implementation, the compiler will not guarantee alignment. So, are you really sure we should do differently in pf, instead of looking for a bridge problem, where bridge constructs an mbuf with the IP header not properly aligned? I've not been sure to begin with. I forwarded this PR because I have no clue as to where the root problem is. If you say that pf(4) is not at fault and it's the bridge code then fine, fix the bridge code. All I see is an unaligned memory access and plenty of yellow flags in the source code. I.e. if the IP header is properly aligned within the mbuf (on 32-bit boundaries, I presume), wouldn't ip_src/dst have to be properly aligned as well, even though __packed is used, because the layout of struct ip is chosen like that? Yes. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Byte counters reset at ~4GB
On Mon, Mar 15, 2004 at 04:05:44PM -0800, Kris Kennaway wrote: > > > > It seems that the byte counters (derived from netstat -nbi) reset at > > around 4 GB. Is there no way around this? It would be nice to be able to > > see an accurate display of totals. It just seems pointless to even have > > this, as 4 GB is just not that much anymore. I know this is a 32bit > > limitation of the variable, but that's just bad coding in my opinion (no > > offence intended), I mean there must be some way around this. > > I think in the past it's been pointed out changing to a 64-bit > variable would slow down the code on non-64-bit architectures like the > venerable i386. Is there a particular reason I don't know about as to why we cannot introduce a MD typedef for counters like this (or even just "long")? I mean, if people make the statement that widening counters is not an option because it slows down some platforms, I must be missing the reason for it to be an all or none kind of issue. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
