linux-kernel - Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh

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] [day] [month] [year] [list]

Date:	Sun, 15 Oct 2006 21:39:38 -0400
From:	Valdis.Kletnieks@...edu
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Jesse Huang <jesse@...lus.com.tw>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, akpm@...l.org, jgarzik@...ox.com
Subject: Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh

On Mon, 16 Oct 2006 07:26:37 +1000, Benjamin Herrenschmidt said:
> Somebody patented FIFO thresholds ? Gack ?

The US PTO is fundamentally busticated.

http://www.engadget.com/2006/10/14/cisco-patents-the-triple-play/

Cisco got a patent on the concept of delivering voice, internet, and
cable TV over one cable.  Now admittedly, when they applied for it in 2000,
it wasn't a buzzword yet - but I'm pretty sure that there was prior art.

Back to the case at hand...

In the case of the TxStartThresh and RxEarlyThresh, I don't think it's
FIFO thresholds per se that are a problem - the note specifically mentioned
cut-through, which is a specific technique of starting to deal with the
alread-arrived head end of the packet *before* the tail end has arrived
yet. e.g. if you read a packet that has 16 bytes of control info followed
by 64 bytes of data, you have finished parsing the first 16 and have set
stuff up by the time the 64 bytes starts arriving - even though you only
started *one* read of 80 bytes).

Of course, even *that* is an old technique - I remember discussion (and
possibly implementation) of being able to read the front of an Ethernet
packet, and do the routing table lookup fast enough so that you could start
transmitting the packet on the outbound interface before it had finished
arriving on the inbound.  Of course, this was back when Proteon and Bay
were start-ups, nobody did IP option fields or router ACLs or stuff like
that, and level-3 routers were not much smarter (and perhaps stupider) than
today's level-2 switches that filter/route based on MAC address...

Maybe the patent is on the fact that you can't do cut-through routing well
without enforcing certain relationships on the Rx and Tx FIFO thresholds...

Content of type "application/pgp-signature" skipped