Re: kernel frameworks for jumbo frame

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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>


  | I agree, I think the latter is better.

I agree, but if that happens, then ...

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

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

kre