Re: zero-copy networking & a performance drop

[Nivedita Singhvi]

On Thu, 27 Jun 2002, Hurwitz Justin W. wrote:

> On Thu, 27 Jun 2002, Nivedita Singhvi wrote:
> 
> [ snip ]
> 
> > That said, rx has been slower than sends in most of our testing
> > too. 
> 
> Is this a documented/explained phemomenon? Or are you and I the only 
> people experiencing it? Do we have any idea as to its cause (or is it 
> inherent architecturally)? 
> 
> Cheers,
> --Gus

Well, briefly, completely speculatively, and possibly unhelpfully,

      - rx side processing can involve more work (stack length
        is simply longer) and so can legitimately take longer.
	This is especially true when options and out of order
	packets are involved, and TCP fast path processing
	on the rx side isnt taken. (I had done a breakdown 
	of this based on some profiles last year, but dont
	have that at the moment)

      - rx side reassembly could cause longer delays in the
        case of fragmentation

      - scheduler comes slightly more into play on the rx
        side for TCP, may be since we can put stuff on the backlog
	or prequeue q's (waiting for a recvmsg()) (??). this is
	again, very off the cuff and based on some profiles
	I had seen on send/rx side with rx side scheduler 
	showing up higher, and without having investigated 
	further at the time..(long time ago, dont quote me, etc..)

	
there are possibly many different scenario's here, and
I'm probably missing the most obvious causes...

thanks,
Nivedita