2014-07-19 2:18 GMT+08:00 Navdeep Parhar npar...@gmail.com
mailto:npar...@gmail.com:
On 07/18/14 00:49, Marcelo Araujo wrote:
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using
igb(4),
ixgbe(4) and em(4); seems everything
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using igb(4),
ixgbe(4) and em(4); seems everything worked pretty well.
I'm wondering if anyone else could make a review, and what I need to do, to
see this patch committed.
Best Regards,
2014-06-24 10:40 GMT+08:00
Hi,
I strongly object to having a round-robin method like this. Yes, we
won't get 1 link of bandwidth out of a single stream, but you're
showing that you can't even get that. There's still something else
weird going on.
I'm sorry, but introducing more out of order possibilities is being a
bad
On 07/18/14 00:49, Marcelo Araujo wrote:
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using igb(4),
ixgbe(4) and em(4); seems everything worked pretty well.
I'm wondering if anyone else could make a review, and what I need to do, to
see this patch committed.
2014-07-19 2:18 GMT+08:00 Navdeep Parhar npar...@gmail.com:
On 07/18/14 00:49, Marcelo Araujo wrote:
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using igb(4),
ixgbe(4) and em(4); seems everything worked pretty well.
I'm wondering if anyone else could make
On 07/18/14 19:06, Marcelo Araujo wrote:
2014-07-19 2:18 GMT+08:00 Navdeep Parhar npar...@gmail.com
mailto:npar...@gmail.com:
On 07/18/14 00:49, Marcelo Araujo wrote:
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using
igb(4),
On 18 July 2014 19:06, Marcelo Araujo araujobsdp...@gmail.com wrote:
2014-07-19 2:18 GMT+08:00 Navdeep Parhar npar...@gmail.com:
On 07/18/14 00:49, Marcelo Araujo wrote:
Hello guys,
I made few changes on the lagg(4) patch. Also, I made tests using
igb(4),
ixgbe(4) and em(4); seems
Hello Adrian,
2014-06-23 12:16 GMT+08:00 Adrian Chadd adr...@freebsd.org:
...
It's an interesting idea, but doing round robin like that may
introduce out of order packets.
Actually, the round robin implementation as it is, causes out of order
packets, but almost all the time SACK can
Hi,
No, don't introduce out of order behaviour. Ever. You may not think
it's a problem for TCP, but UDP things and VPN things will start
getting very angry. There are VPN configurations out there that will
drop the VPN if frames are out of order.
The ixgbe driver is setting the flowid to the
2014-06-24 6:54 GMT+08:00 Adrian Chadd adr...@freebsd.org:
Hi,
No, don't introduce out of order behaviour. Ever.
Yes, it has out of order behavior; with my patch much less. I upload two
pcap files and you can see by yourself, if you don't believe in what I'm
talking about.
Test done using:
Hello guys,
I made some changes on roundrobin protocol where from now you can via
sysctl(8) set a better packets distribution among the interfaces that are
part of the lagg(4) group.
My motivation for this change was interfaces that use TSO, as example
ixgbe(4), the performance is terrible, as
...
It's an interesting idea, but doing round robin like that may
introduce out of order packets.
What's the actual problem you're seeing? Are the transmit queues
filling up? Is the distribution with flowid/curcpu not good enough?
Scott saw this happen at Netflix. He added a lagg twiddle to set
12 matches
Mail list logo
