tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel frameworks for jumbo frame




> On Jan 31, 2019, at 12:08 AM, Masanobu SAITOH <msaitoh%execsw.org@localhost> wrote:
> 
> Hi, all.
> 
> I'm sorry for being little late.

Better late than never?  (Hopefully, that includes this reply...) :-)

> I'm also one of the man who don't want to use property carelessly.
> The reason is almost the same as kre's.
> 
> A few months ago, I surveyed the diversity of "struct ifreq",
> "struct if_media", if_flags, and ifcaps among {Net,Open,Free,DragonFly}BSD
> and MacOS(xnu). It was caos. One of big problem and the reason of the
> caos is that almost all OSes don't do correct layering.

You will certainly get no argument from me on that point.  In many ways, the BSD network stack is nice.  Yet also, in many ways, it is horrible.

> I thinks an interface's MTU and the Layer 2's frame size should be
> distinct.

//YES//

> For Ethernet, the frame format is shared with some other protocols,
> so such type of structures should be shared (e.g. our ec_cap*).
> (XXX Last month, I added ETHERCAP_EEE into ec_cap{abilities,enable}.
> I think it's not good because 802.11 doesn't have it. If we have
> a good framework under the layer, it would be good to move EEE stuff
> into it, but I think moving EEE stuff into if_media is not good.)
> 
> if_media is used for more than 20 years. In this two decades, a lot
> of media and a lot of optional features have been added. It's too
> difficult to add optional features depend on a media, so I think
> if_media should be simple and move some feature options to some other
> location (new data structure).

Have you read Dennis Ferguson's thoughts on the subject?  In addition to his AsiaBSDCon '15 presentation, I think there's a paper with even more detail.  I'm not 100% sold on Dennis's user-visible naming conventions[*], but boy oh boy would a layering scheme like his proposal be so much better.

[*] While I used like exposing the driver name to the user (e.g. "wm0" and "urtwn0"), I think a better user-visible naming convention is something like "eth0" and "wifi0", no matter the underlying driver.  Of course, a mapping from "eth0 -> wm0" and "wifi0 -> urtwn0" mapping should be visible to the user should they decide to care about it, but I'd argue that most people don't, and if they happen to switch to a different USB wifi or ethernet dongle, a generic name saves some annoying busy work.  I also think that a way to optionally pin e.g. "eth0" to a physical hardware location would be useful (so that e.g. an on-board Ethernet interface is always "eth0" regardless of when expansion slots get enumerated, etc.).

In Dennis's scheme, "wm0" would still be the ifdevice_t name, but my preference would be for "iflogical_t" to be named e.g. "eth0" rather than "wm0.2", for example.

> If someone design a good frame work I'll help to implement it.
> 
> Thanks.

-- thorpej



Home | Main Index | Thread Index | Old Index