netdev
[Top] [All Lists]

Re: [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs

To: hadi@xxxxxxxxxx
Subject: Re: [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 20 Dec 2004 17:02:22 -0800
Cc: kaber@xxxxxxxxx, tgraf@xxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <1103552026.1048.324.camel@jzny.localdomain>
References: <20041218170017.GH17998@postel.suug.ch> <1103487827.1048.188.camel@jzny.localdomain> <20041219203641.GL17998@postel.suug.ch> <41C687EE.1090205@trash.net> <1103552026.1048.324.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
On 20 Dec 2004 09:13:46 -0500
jamal <hadi@xxxxxxxxxx> wrote:

> Certainly not a big deal; shouldnt care if once in a while tcpdump
> actually gets to see the real packet that went out the wire.

It's not just tcpdump.  Any modification of a the packet data
for a shared SKB is illegal, no matter where it occurs.
This can corrupt TCP packets, which share the transmitted
packet with the socket retransmit queue.

We have a similar problem with TSO and some gigabit cards whose
drivers muck with the iphdr->tot_len field on transmit.  I still
am not sure how I want to address that case yet.  Since transmitted
TCP data packets are always shared/cloned, we'll have to do a data
copy on every TSO send on these cards which frankly nullifies much
of the performance gain TSO gives.  If we end of fixing it via a copy
we'll probably need to seriously consider not doing TSO unless we
are doing sendfile.

<Prev in Thread] Current Thread [Next in Thread>