| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] PKT_SCHED: Fix cls indev validation, David S. Miller |
|---|---|
| Next by Date: | Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way), Peter Chubb |
| Previous by Thread: | Re: [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs, jamal |
| Next by Thread: | Re: [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |