On 8 Feb 2015, at 22:41, Mike Karels wrote:
Sorry to reply to a thread after such a long delay, but I think it is
unresolved, and needs more discussion. I'd like to elaborate a bit on
my goals and proposal. I believe Adrian has newer thoughts than have
been
circulated here as well.
The last message(s) have gone to freebsd-arch and freebsd-net. If
someone
wants to pick one, we could consolidate, but this seems relevant to
both.
I'm going to top-post to try to summarize and extend the discussion,
but the
preceding emails follow for reference.
To recap: the existing if_media interface is running out of steam, at
least
in that the "Media variant" field, with 5 bits, is going to be
insufficient
to express existing 40 Gb/s variants. The if_media media type is a
32-bit
int with a bunch of sub-fields for type (e.g. Ethernet),
subtype/variant
(e.g. 10baseT, 10base5, 1000baseT, etc), flags, and some MII-related
fields.
I made a proposal to extend the interface in a small way, specifically
to
replace the "media word" with a 64-bit int that is mostly the same,
but
has a new, larger variant/subtype field. The main reason for this
proposal
is to maintain the driver KPI (glimpse showed me 240 inclusions of
if_media.h
in the kernel in 8.2). That interface includes an initialization
using a
scalar value of fields ORed with each other. It would also be easy to
preserve a 32-bit user-level API/ABI that can express most of the
current
state, with a subtype/variant field value reserved for "other" (there
is
already one for "unknown", but that is not quite the same). fwiw, I
found 45 references to this user-level API in our tree, including both
base and "ports"-type software, which includes libpcap, snmpd,
dhclient,
quagga, xorp, atm, devd, and rtsold, which argues for a
backward-compatible
API/ABI as well as a more-complete current interface for ifconfig at
least.
More generally, I see two problems with the existing if_media
interface:
1. It doesn't have enough bits for all the fields, in particular,
variant/
subtype for Ethernet. That is the immediate issue.
2. The interface is not sufficiently generic; it was designed around
Ethernet
including MII, token ring, FDDI, and a few other interface types.
Some of
the fields like "instance" are primarily for MII as far as I know, and
are
basically unused. It is definitely not sufficient for 802.11, which
has
rolled its own interfaces.
To solve the second problem, I think the right approach would be to
reduce
this interface to a truly generic one, such as media type (e.g.
Ethernet),
generic flags, and perhaps generic status. Then there should be a
separate
media-specific interface for each type, such as Ethernet and 802.11.
To a
small extent, we already have that. Solving the second, more general
problem,
requires a whole new driver KPI that will require surgery to every
driver,
which is not an exercise that I would consider.
Using a separate int for each existing field, as proposed, would break
the
driver KPI, but would not really make the interface generic. Trying
to
make a single interface with the union of all network interface
requirements
seems like a bad idea to me (we failed last time; the "we" is BSDi,
where
I was the architect when this interface was first designed). (No, I
didn't
design this interface.)
Solving the first problem only, I think it is preferable to preserve a
compatible driver KPI, which means using a scalar value encoding what
is
necessary. Although that interface is rather Ethernet-centric, that
is
really what it is used for.
An additional, selfish goal is to make it easy to back-port drivers
using
the new interface to older versions (which I am quite likely to do).
Preserving the KPI and general user API will be highly useful there.
I'd be likely to do a 11-style version of ifconfig personally, but it
might not be difficult to do in a more general way.
I am willing to do a prototype for -current for evaluation.
Comments, alternatives, ?
I agree with your statements above and I'd like to see the prototype.
Best,
George
Mike
From: Eric Joyner <e...@erj.cc>
Date: January 6, 2015 4:50:28 PM CST
To: m...@karels.net
Cc: Adrian Chadd <adr...@freebsd.org>, Rui Paulo <rpa...@me.com>,
"freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Eric Joyner
<e...@erj.cc>, John Baldwin <j...@baldwin.cx>, Jack Vogel
<jfvo...@gmail.com>, "freebsd-a...@freebsd.org"
<freebsd-a...@freebsd.org>
Subject: Re: Adding new media types to if_media.h
Then going with what Mike says about leaving backwards compatibility,
I
suppose we should do something like what Adrian suggested, and add a
separate struct. We can indicate that the separate struct exists by
setting
the media type value in the if_media word to 0xc0, since that's the
last
unused value. Then existing programs won't have to support any new
features
if they don't want to.
Adrian -- where can I look for more information on what net80211 does
for
media types? Do you mean what it does with MCS values, or something
more;
I've looked at it a bit, but I don't know very much about how Wi-Fi
works.
- Eric
On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels <m...@karels.net> wrote:
On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote:
I think I'd go along with Mike, keeping it simpler seems like a
good
idea.
Jack
If the userland ABI impact isn't too broad I think this is fine.
Mike,
do you
know off hand how many user-facing things would be affected?
I didn't know off hand, but I have a glimpse index at $WORK (it's
for
McAfee
Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45
references
to
if_media.h at user level, including "ports" that we use, and
excluding our
own software. The list includes libpcap, snmpd, dhclient, quagga,
xorp,
atm, devd, and rtsold. fwiw, I found about 260 inclusions of
if_media.h
in the kernel.
This suggests that we should preserve a backward-compatible user
API, even
if it has limits. Unfortunately, the media word I mentioned is a
plain
int,
not a typedef. I would propose a similar API that is not limited,
but easy
to convert (e.g. using a new typedef). I'd be willing to sketch out
something
like that.
On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels <m...@karels.net>
wrote:
Any other thoughts, or should I start looking at seeing what I
can
take
copy from net80211?
Also adding -net, since this is pretty relevant.
I had the same reaction as Adrian initially, as an int with
numerous
fields
seems really messy. However, I don't think we have the
challenges of
802.11,
and the only real problem is that the subtype field has run out
of
bits.
And both ifconfig and the drivers are cast in the form of a
scalar
"media
word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T
|
IFM_FDX
(assuming that all the bits are in a scalar).
Instead, I would propose that we simply change the media word
from
32 bits
to 64, and move the subtype from its current location to a new
field
(e.g.
16 bits) in the new space. I believe this can be KPI compatible,
and it
is relatively easy to provide a backward-compatible ABI. There
should be
a reserved subtype for "other" that can be encoded in the
existing
field
for use when the subtype can't fit in the old field. This seems
much
easier,
can be KPI compatible, and will make it much easier to backport
drivers.
A backport could simply define the new subtypes as "other", and
the
KPI
would still be compatible.
Thoughts?
Mike
--
John Baldwin
Mike
_______________________________________________
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"
_______________________________________________
freebsd-a...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to
"freebsd-arch-unsubscr...@freebsd.org"
_______________________________________________
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"
