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 <j...@netgate.com> wrote:
> On May 4, 2015, at 10:07 PM, Julian Elischer <jul...@freebsd.org
<mailto:jul...@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@freebsd.org <mailto:freebsd-net@freebsd.org> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscr...@freebsd.org
<mailto:freebsd-net-unsubscr...@freebsd.org>"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
