Re: zero-copy networking & a performance drop

From: Nivedita Singhvi (
Date: Thu Jun 27 2002 - 17:33:33 EST

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...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:12 EST