netdev - Re: [RFC] tcp: add support for scheduling TCP options on TCP sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 07 May 2014 01:38:20 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	octavian.purdila@...el.com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC] tcp: add support for scheduling TCP options on TCP
 sockets

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.

I also disagree with the "if the option doesn't fit, send it in the
next packet" idea.  Where did that come from?

For SACK for example, that doesn't make any sense, and it's SACK
that usually can put us past the amount of space available.  For
SACK the thing to do is send the SACK information for the area
closest to what we've fully ACKd and just forget about advertising
the rest of the SACK blocks.
--
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