On Thu, Aug 25, 2016 at 12:19 PM, Alexander Duyck
wrote:
> On Wed, Aug 24, 2016 at 4:46 PM, Rick Jones wrote:
>> Also, while it doesn't seem to have the same massive effect on throughput, I
>> can also see out of order behaviour happening when the sending VM is on a
>> node with a ConnectX-3 Pro
On Thu, Aug 25, 2016 at 1:18 PM, Rick Jones wrote:
> On 08/25/2016 12:19 PM, Alexander Duyck wrote:
>>
>> The problem is that there is no socket associated with the guest from
>> the host's perspective. This is resulting in the traffic bouncing
>> between queues because there is no saved socket
On 08/25/2016 12:19 PM, Alexander Duyck wrote:
The problem is that there is no socket associated with the guest from
the host's perspective. This is resulting in the traffic bouncing
between queues because there is no saved socket to lock the interface
onto.
I was looking into this recently as
On Wed, Aug 24, 2016 at 4:46 PM, Rick Jones wrote:
> Also, while it doesn't seem to have the same massive effect on throughput, I
> can also see out of order behaviour happening when the sending VM is on a
> node with a ConnectX-3 Pro NIC. Its driver is also enabling XPS it would
> seem. I'm not
Also, while it doesn't seem to have the same massive effect on
throughput, I can also see out of order behaviour happening when the
sending VM is on a node with a ConnectX-3 Pro NIC. Its driver is also
enabling XPS it would seem. I'm not *certain* but looking at the traces
it appears that wit
Back in February of this year, I reported some performance issues with
the ixgbe driver enabling XPS by default and instance network
performance in OpenStack:
http://www.spinics.net/lists/netdev/msg362915.html
I've now seen the same thing with be2net and Skyhawk. In this case, the
magnitude