svn commit: r258328 - head/sys/net

Luigi Rizzo rizzo at iet.unipi.it
Thu Nov 21 00:32:49 UTC 2013


On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote:
> Hi,
> 
> We should migrate drivers to use a multi-input method where it's
> appropriate. It's the same pain as if_transmit() is/was.

right, and i think that is very confusing and i'd rather
not replicate the experience.

But what is your plan, have both if_input and if_input_multi ?
And then make the vlan and all similar filters intercept both ?
Because all of the existing options have pros and cons:

1. having both if_input and if_input_multi is visually cleaner
   but requires extending ifnet and some convoluted code in the
   initialization (same as if_transmit)
   
2. just if_input with typed mbufs is less clean but has the big
   advantage thay you only need to change ether_input() (and equivalent
   for other L2 protocols), and it is not error prone

3. having only if_input_multi (even without renaming if_input)
   requires you to change all the 100+ drivers.

It seems to me that #2 at least preserves binary compatibility
with driver modules and is easier to backport to other versions
of FreeBSD, this is why i prefer it.

my two cents...

	cheers
	luigi

> I'd really like to avoid having hacky solutions like mbufs with magic
> types. If we're going down that path, we should create a correct
> inline messaging mechanism that includes arbitrary messages in the
> stream, where some may or may not be mbufs. Magic mbufs just makes me
> want to tear out my eyes a little.
> 
> So, the reason I'd like to back it out is because we should be doing
> it via a multi method with some type that represents an mbuf list. If
> George doesn't mind, I'll add a multi input method, move this stuff
> into it, and make ether_input just be single frames.
> 
> 
> 
> -adrian


More information about the freebsd-net mailing list