On Thursday, January 26, 2017, Espen Johansen <[email protected]> wrote:
> Are you saying worst case is 80%? Its not normal to have all minimum size > packets unless you are under ddos. > Default ethernet is 1526 (1530 with vlan) with a MTU 1500 on a layer 1 > frame. > A layer 2 frame is 1518 (1522 with vlan). > If you want to include all layer headers then 1542 including vlan is the > correct number and that will allow a 1500 octet payload. Yes, I know, but adding a vlan tag means the small frame size isn't "smallest". I was just throwing that in for comparison. Point is, on a 10g network, the maximum frame rate is 14.88 mpps. This is the highest rate required by the network under any circumstance. It's also how you have to think about the problem if you're not going to engage in making excuses. If you still don't like it, consider that: - 40g Ethernet cards exist today, so being able to forward 256 byte packets at 40gbps will require the same 14.88 mpps rate, - nx25 is the future in the data center vswitches and vrouters are a thing, and pfSense should be able to play in this market - 10g is starting to appear on lower-end hardware. - 10g switches are starting to hit $100/port And also that netgate has product coming in 2017 that folds multiple integrated switch ports into a single 2.5gbps or multiple 10gbps Ethernet uplink ports. Remember, we're doing this in software. No ASICs required. That 12mpps figure on an 8 core Rangeley includes 50 ACLs in the path. BTW, average frame size on the Internet is just under 600 bytes, btw. Not 1200 as you guessed. Jim > > On Thu, Jan 26, 2017, 18:20 Jim Thompson <[email protected] <javascript:;>> > wrote: > > > > On Jan 26, 2017, at 5:06 PM, [email protected] <javascript:;> > wrote: > > > > > > Am 2017-01-26 07:03, schrieb Jim Thompson: > > >> It does not. > > >> The c2758 SoC is interesting. 8 cores, and the on-die i354 is > > essentially a > > >> block with 4 i350s on it. > > >> These have 8 queues for each of rx and tx, so 16 each, for a total of > 64 > > >> queues. > > >> On the c2xxx series (and other) boxes we ship, we increase certain > > >> tunables, because we know what we're installing onto, and can adjust > > that > > >> factory load. pfSense CE does not have that luxury, it has to run on > > nearly > > >> anything the community finds to run it on. Some of these systems have > > ... > > >> constrained RAM. While we test each release on every model we ship, > > such > > >> testing takes place only for a handful of other configurations. > > >> There is a decent explanation of some of the tunables here: > > >> https://wiki.freebsd.org/NetworkPerformanceTuning > > >> Incidentally, FreeBSD, and thus pfSense can't take much advantage of > > those > > >> multqueue NICs, because the forwarding path doesn't have the architure > > to > > >> advantage them. Our DPDK-based system can forward l3 frames at over > > 12Mpps > > >> on this hardware (about 80% of line-rate on a 10g interface). > > >> Neither pfSense or FreeBSD (nor Linux) will do 1/10th of this rate. > > > > > > > > > > > > > > > Hi, is this DPDK-based system commercially available? > > > > > > > > > > > > Rainer > > > > Still being developed. > > > > Jim > > _______________________________________________ > > pfSense mailing list > > https://lists.pfsense.org/mailman/listinfo/list > > Support the project with Gold! https://pfsense.org/gold > > > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
