netdev
[Top] [All Lists]

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

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [PATCH] PKT_SCHED: dsmark must take care of shared/cloned skbs
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 22 Dec 2004 14:50:30 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, kaber@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <1103721246.1093.39.camel@xxxxxxxxxxxxxxxx>
References: <20041218170017.GH17998@xxxxxxxxxxxxxx> <1103487827.1048.188.camel@xxxxxxxxxxxxxxxx> <20041219203641.GL17998@xxxxxxxxxxxxxx> <41C687EE.1090205@xxxxxxxxx> <1103552026.1048.324.camel@xxxxxxxxxxxxxxxx> <20041220170222.5ee14588.davem@xxxxxxxxxxxxx> <1103721246.1093.39.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* jamal <1103721246.1093.39.camel@xxxxxxxxxxxxxxxx> 2004-12-22 08:14
> On Mon, 2004-12-20 at 20:02, David S. Miller wrote:
> > 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.
> 
> Ok, makes sense. I can see how TSO may not be useful if you have to
> copy. I suppose NICS with hardware based retransmits will behave
> differently.

I think we should move all packet manngling to be an action and warn
about the loss of performance. We might be able to add a fast path for
simple modifications such as dsmark dscp maping and other simple header
modifications by not copying but mangle the fragment itself assuming we
can accept some drawbacks with packet sockets. More advanced mangling
as done by pedit is less of a problem since it will likely be used
in combination with heavy filtering but we could of course do some
analysis of the edit request and go the fast path under some
circumstances.

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