On Tue, 2014-06-03 at 14:54 +0300, Igor Royzis wrote:
> Eric, could you please provide a feedback on the suggestion to move
> the pointer from skb_shared_info to skbuff? If we must fit
> skb_shared_info till the 'frags' field into 1 cache line (I honestly
> don't quite understand why (the whole str
Eric, could you please provide a feedback on the suggestion to move
the pointer from skb_shared_info to skbuff? If we must fit
skb_shared_info till the 'frags' field into 1 cache line (I honestly
don't quite understand why (the whole structure as well as the skb's
data will always require > 1 cache
On Sun, Jun 01, 2014 at 02:39:39PM +0300, Igor Royzis wrote:
> The patch discussion seems got lost due to a delay it took us to get
> the numbers. We believe that a 24% improvement in VM's network
> performance (and probably the better improvement the more guests are
> running on a host) is worth c
The patch discussion seems got lost due to a delay it took us to get
the numbers. We believe that a 24% improvement in VM's network
performance (and probably the better improvement the more guests are
running on a host) is worth commenting and getting to some conclusion.
> Before your patch :
>
>
On Tue, May 20, 2014 at 5:28 PM, Eric Dumazet wrote:
> On Tue, 2014-05-20 at 14:24 +0300, Igor Royzis wrote:
>> Fix accessing GSO fragments memory (and a possible corruption therefore)
>> after
>> reporting completion in a zero copy callback. The previous fix in the commit
>> 1fd819ec
>> orphane
> If true, I'd like to see some performance numbers please.
The numbers have been obtained by running iperf between 2 QEMU Win2012
VMs, 4 vCPU/ 4GB RAM each.
iperf parameters: -w 256K -l 256K -t 300
Original kernel 3.15.0-rc5: 34.4 Gbytes transferred, 984
Mbits/sec bandwidth.
Kernel 3.15
On Tue, May 20, 2014 at 09:05:38AM -0700, Eric Dumazet wrote:
> On Tue, 2014-05-20 at 07:28 -0700, Eric Dumazet wrote:
> > On Tue, 2014-05-20 at 14:24 +0300, Igor Royzis wrote:
> > > Fix accessing GSO fragments memory (and a possible corruption therefore)
> > > after
> > > reporting completion in
On Tue, 2014-05-20 at 07:28 -0700, Eric Dumazet wrote:
> On Tue, 2014-05-20 at 14:24 +0300, Igor Royzis wrote:
> > Fix accessing GSO fragments memory (and a possible corruption therefore)
> > after
> > reporting completion in a zero copy callback. The previous fix in the
> > commit 1fd819ec
> > o
On Tue, 2014-05-20 at 14:24 +0300, Igor Royzis wrote:
> Fix accessing GSO fragments memory (and a possible corruption therefore) after
> reporting completion in a zero copy callback. The previous fix in the commit
> 1fd819ec
> orphaned frags which eliminates zero copy advantages. The fix makes the
Hi Michael,
You're absolutely right.
We detected the actual corruption running MS HCK on earlier kernels,
before the 1fd819ec, so the patch was developed as a fix for this issue.
However, 1fd819ec fixes the corruption and now it's only an optimization
that re-enables the zero copy for this case.
On Tue, May 20, 2014 at 02:24:21PM +0300, Igor Royzis wrote:
> Fix accessing GSO fragments memory (and a possible corruption therefore) after
> reporting completion in a zero copy callback. The previous fix in the commit
> 1fd819ec
> orphaned frags which eliminates zero copy advantages. The fix ma
11 matches
Mail list logo
