On Fri, Jul 4, 2014 at 12:16 PM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:

> On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote:
> > >
> > > In real world "Reality is quite different than it actually is".
> > >
> > >
> http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html
> > >
> > > See "Packet Path Theory of Operation. Ingress Mode".
> > >
> > >
> > Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is
> > really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G
> form.
> >
> > Note that they don't make any claim of 802.3ba compliance. It only states
> > that "40 Gigabit Ethernet is now part of the IEEE 802.3ba standard." So
> it
> > is, but this device almost certainly predates the completion of the
> > standard to get a product for which there was great demand. It's a data
> > center product and for typical cases of large numbers of small flow, it
> > should do the trick. Probably does not interoperate with true 80-2.3ba
> > hardware, either.
> >
> > My boss at the time I retired last November was on the committee that
> wrote
> > 802.3ba. He would be a good authority on whether the standard has any
> vague
> > wording that would allow this, but he retired 5 month after I did and I
> > have no contact information for him. But I'm pretty sure that there is no
> > way that this is legitimate 40G Ethernet.
> 802.3ba describe only end point of ethernet.
> ASIC, internal details of implemetations NICs, switches, fabrics --
> out of standart scope.
> Bottleneck can be in any point of packet flow.
> In first pappers of netmap test demonstarated NIC can't do saturation
> of 10G in one stream 64 bytes packet -- need use multiple rings for
> transmit.

​that was actually just a configuration issue which since then
has been ​resolved. The 82599 can do 14.88 Mpps on a single ring
(and is the only 10G nic i have encountered who can do so).
Besides, performance with short packets has nothing to do with the case
you were discussing, namely throughput for a single large flow.

> I think need use general rule: one flow transfer can hit performance
> limitation.

​This is neither a useful nor it is restricted to a single flow.

Everything "can" underperform depending
on the hw/sw configuration, but not necessarily has to.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to