Re: kernel frameworks for jumbo frame

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

Hi, all.

 I'm sorry for being little late.

On 2019/01/31 14:21, Rin Okuyama wrote:
> On 2019/01/30 23:47, Jason Thorpe wrote:
> > > On Jan 30, 2019, at 3:29 PM, Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> > >
> > > | Yes, I think something like:
> > >   |
> > >   |     size_t mbuf_cluster_size_for_size(size_t desired_size);
> > >
> > > whatever the name, is unlikely to be needed, that would be
> > > used in the "must specify a supportyed size" variant of the
> > > former, rather than the "pick a supported size that will handle
> > > the request" version that you thought was better (as do I.)
> >
> > I suppose you're right ... I was thinking that there might be some utility to exposing the information, in the event that it could be useful for some drivers.  I could certainly be left out for now, and exposed at a later time if there was a concrete use for it.
>
> OK. I will write a draft, possibly in this weekend.
>
> On 2019/01/30 22:29, Robert Elz wrote:
> >      Date:        Wed, 30 Jan 2019 13:07:02 +0200
> >      From:        Jason Thorpe <thorpej%me.com@localhost>
> >      Message-ID:  <F109B171-90D8-4C1A-82C1-3F03066B3CC0%me.com@localhost
> ...
> >    | The idea would be that instead of adding additional property fields
> >    | to struct ifnet, you could add either a prop_dictionary_t or nvlist
> >
> > Yes, we know that you like property lists ...
> >
> > They have the advantage that the structs don't need to
> > keep changing nearly as often when new data is needed,
> > with the consequential kernel version bumps (and so, it
> > becomes possible to pull up any changes which require a
> > new property with new date) but the disadantage that it
> > is easy for every developer, of every driver (or whatever),
> > their dog, and each of the dog's fleas, to all add new
> > properties, ignoring what was done by each of the others,
> > fail to document them properly (UTSL!) and we end up with
> > a completely incomprehensible mess, which no-one can
> > use or understand.

 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.

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

 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).

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

 Thanks.

> Well, I also feel it little bit too much... Anyway, I will write a
> patch to see what it looks like.
>
> On 2019/01/30 21:59, Christos Zoulas wrote:
> > In article <20190130110317.GC28471%mail.duskware.de@localhost>,
> > Martin Husemann  <martin%duskware.de@localhost> wrote:
> > > On Wed, Jan 30, 2019 at 07:59:13PM +0900, Rin Okuyama wrote:
> > > > I think we agree to add API something like
> > > >
> > > > On 2019/01/29 17:32, Maxime Villard wrote:
> > > > >       int
> > > > >       m_addjcl(struct mbuf *m, int how, int size)
> > >
> > > Just a minor nit: avoid "JCL" in any names - it causes great pain for some
> > > readers.
> >
> > It is the function that adds support for the Job Control Language to mbufs.
>
> Oops...
>
> Thanks,
> rin


--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)