[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20140507.124859.310105705013032741.davem@davemloft.net>
Date: Wed, 07 May 2014 12:48:59 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: octavian.purdila@...el.com
Cc: netdev@...r.kernel.org, christoph.paasch@...ouvain.be
Subject: Re: [RFC] tcp: add support for scheduling TCP options on TCP
sockets
From: Octavian Purdila <octavian.purdila@...el.com>
Date: Wed, 7 May 2014 10:30:23 +0300
> On Wed, May 7, 2014 at 8:38 AM, David Miller <davem@...emloft.net> wrote:
>>
>> From: Octavian Purdila <octavian.purdila@...el.com>
>> Date: Tue, 6 May 2014 21:05:24 +0300
>>
>> > Pardon the rough patch, but I hope it is enough to get some feedback
>> > on the overall approach.
>>
>> Sorry I don't like this.
>>
>> Walking a linked list unnecessary is going to add overhead to every
>> single packet transmission. I think more people want our TCP stack to
>> be fast (everyone) than those who want option processing to be
>> abstracted enough to be modular (you).
>>
>> Just make the intrusive changes, they are necessary as they force you
>> to think fully about how one option might interact with another.
>>
>
> Unfortunately skb_tcp_cb does not have enough space to hold
> information for new large options. To work around that, the MPTCP
> implementation is pushing the option data in the skb and then
> occasionally uses the following when the pskb_copy is used:
Why not deal with the problem directly by trying to find a way to
compress the existing use of skb_tcp_cb() so that there is actually
the amount of space you need?
That is the approach I definitely prefer you take.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists