Re: kernel frameworks for jumbo frame

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jan 30, 2019, at 12:59 PM, Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost> wrote:
> 
> Jason, Maxime, thank you for helpful comments!
> 
> 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)
> 
> or
> 
> On 2019/01/29 17:31, Jason Thorpe wrote:
>> 	int	mbuf_get_cluster(struct mbuf *m, size_t desired_size);
> 
> I would like to write a draft of patch. Here, how should we treat size
> argument; (a) cluster size itself (like FreeBSD), or (b) minimum required
> size of cluster (like OpenBSD)? IMO, the latter is better; the overhead
> should be negligible for modern processors. Otherwise, in addition to

I agree, I think the latter is better.

> On 2019/01/29 17:31, Jason Thorpe wrote:
>> Probably worth having a call that returns the maximum cluster size available:
>> 
>> 	size_t mbuf_max_cluster_size(void);
> 
> function, we may need a function which returns a cluster size
> corresponding to a required size. Is it too much?

Yes, I think something like:

	size_t mbuf_cluster_size_for_size(size_t desired_size);

...(or similar -- I understand some might find that name too verbose :-) would be a good and reasonable addition.

> I don't understand where the value of "ethernet-max-mtu" itself is
> stored? I don't think it is not so bad idea to have something like
> if_maxmtu member in struct ifnet; it can also be used in the future
> for other media that support variable MTU.

The idea would be that instead of adding additional property fields to struct ifnet, you could add either a prop_dictionary_t or nvlist or whatever (I obviously have my own preference, but I'll leave that aside :-) that allows for arbitrary properties to be added.  None of these things are generally consulted in critical performance paths, only during configuration events.

-- thorpej