Re: kernel frameworks for jumbo frame

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

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.

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