netmap-ipfw on em0 em1

Wed May 6 04:47:32 UTC 2015

On 5/5/15 10:46 PM, Barney Cordoba wrote:
> Are you NOT SHARP ENOUGH to understand that my proposal DOESN'T USE 
> THE NETWORK STACK? OMFG

Barney, your proposal is that we provide a framework to allow network 
IP stack bypass in the case of special processing.
that framework still needs to be hooked into the system and IS STILL 
PART OF THE NETWORKING STACK, lying between the driver layer and the 
protocol layer.
In this space we already have a whole bunch of  "intercept" hooks. 
(bpf, netgraph, filters, bridging, vlans, even netmap (which can be 
used from within the kernel as well as from external to it.)

if you really want to be productive, figure out what you need, how it 
fits in with what is already there, (maybe it can USE what's already 
there), and give us some design sketches. We are not going to do it 
for you, we have our own fires to quench and itches to scratch. I have 
a full time job doing "other stuff" right now.  We WILL however 
happily discuss your designs and suggestions with you when they are 
more concrete than "hey I like apple pie". Work up a simple proof-of 
concept.. it's not that hard..
I had netgraph proofed up in about a day..  We all know we need work 
in this space. having you tell us that again doesn't give us more free 
time. but YOU obviously have some time We welcome your interest and 
hope to profit by your obvious expertise in this area.   I'm not being 
aggressive. I'm just hoping to get some free labour out of you :-)

>
> Julien, perhaps if people weren't so hostile towards commercial 
> companies providing ideas for alternative ways of doing things you'd 
> get more input and more help. Why would I want to help these people?

BTW since I'm not French my name is Julian. And I am not being 
hostile. I'm just saying what the facts are..
Yes work needs to be done.  yes there are too few people to do it..

But please don't make suggestions and just expect that everyone will 
put down their picks and be so overawed by the total amazingness of 
your suggestions that they all rush to do it for you. Things I have 
done (often with others) have been because I thought they need to be 
done.. They were also things that I needed.

Bios based bootblocks 1992,  scsi system 1993, devfs 1994 netgraph 
1996, divert 1995 threads 1999-2002  scheduler fixes 2004? USB fixes 
2003 multiple fibs 2007 vimage 2010+ (ish) .. (then kids, work , work, 
etc.)
(and others I forgot).
none of these things were done because an amazing genius suggested it 
and then went away.

> .
> BC

J

>
>
>
> On Monday, May 4, 2015 11:55 PM, Jim Thompson <jim at netgate.com> wrote:
>
>
>
> > On May 4, 2015, at 10:07 PM, Julian Elischer <julian at freebsd.org 
> <mailto:julian at freebsd.org>> wrote:
> >
> > Jim, and Barney. I hate to sound like a broken record, but we 
> really need interested people in the network stack.
> > The people who make the decisions about this are the people who 
> stand up and say "I have a  few hours I can spend on this".
> > If you were to do so too, then really, all these issues could be 
> worked on. get in there and help rather than standing on the 
> bleachers and offering advise.
> >
> > There is no person working against you here.
> >
> > From my counting the current active networking crew is about 10 
> people. with another 10 doing drivers.
> > You would have a lot of sway in a group that small. but you have 
> th be in it first, and the way to do that is to simple start doing 
> stuff.  no-one was ever sent an invitation. They just turned up.
>
>
> I am (and we are) interested.  I’m a bit short on time, and I have a 
> project/product (pfSense) to maintain, so I keep other people busy 
> on the stack.
>
> Examples include:
>
> We co-sponsored the AES-GCM work.  Unfortunately, the process 
> stopped before the IPsec work to leverage this we did made it upstream.
> As partial remedy, gnn is currently evaluating all the patches from 
> pfSense for inclusion into the FreeBSD mainline.
>
> I was involved in the work to replace the hash function used in pf.  
> This is (only) min 3% gain, more if you carry large state tables.
>
> There was a paper presented at AsiaBSDcon, so at least we have a 
> methodology to speak about performance increases.  (Is the 
> methodology in the paper perfect? No.  But at least it’s a stake in 
> the ground.)
>
> We’re currently working with Intel to bring support for QuickAssist 
> to FreeBSD.  (Linux has it.)  While that’s not ‘networking’ per-se, 
> the larger consumers for the technology
> are various components in the stack.
>
> The other flaws I pointed out are on the list of things for us to 
> work on / fix.  Someone might get there first, but … that’s good.  I 
> only care about getting things fixed.
>
> Jim
> p.s.  yes, I'm working on a commit bit.
>
>
>
> _______________________________________________
> freebsd-net at freebsd.org <mailto:freebsd-net at freebsd.org> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to 
> "freebsd-net-unsubscribe at freebsd.org 
> <mailto:freebsd-net-unsubscribe at freebsd.org>"
>
>