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

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

[Andrew Morton]

On Mon, 02 Oct 2006 14:23:51 -0400
Jesse Huang <jesse@icplus.com.tw> wrote:

> For pattern issue need to remove TxStartThresh and RxEarlyThresh.

Please describe this issue more completely.

What are the implications of simply removing this feature?  Presumably that
code was there for a reason..

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

[Roland Dreier]

 > > For pattern issue need to remove TxStartThresh and RxEarlyThresh.

 > Please describe this issue more completely.
 > 
 > What are the implications of simply removing this feature?  Presumably that
 > code was there for a reason..

Actually I think this patch needs to be handled delicately -- because
based on earlier emails from Jesse (http://www.mail-archive.com/netdev@vger.kernel.org/msg22254.html),
I am pretty sure that "pattern" is a typo for "patent".  So I guess
the question is what exactly the patent covers and what the
implications of having the current kernel code are.

 - R.

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

[Jesse Huang]

Sorry, I had typed wrong word.

It is because patent issue.

Thnaks.
----- Original Message ----- 
From: "Roland Dreier" <rdreier@cisco.com>
To: "Andrew Morton" <akpm@osdl.org>
Cc: "Jesse Huang" <jesse@icplus.com.tw>; <linux-kernel@vger.kernel.org>;
<netdev@vger.kernel.org>; <jgarzik@pobox.com>
Sent: Monday, October 02, 2006 3:00 PM
Subject: Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh


> > For pattern issue need to remove TxStartThresh and RxEarlyThresh.

 > Please describe this issue more completely.
 >
 > What are the implications of simply removing this feature?  Presumably
that
 > code was there for a reason..

Actually I think this patch needs to be handled delicately -- because
based on earlier emails from Jesse
(http://www.mail-archive.com/netdev@vger.kernel.org/msg22254.html),
I am pretty sure that "pattern" is a typo for "patent".  So I guess
the question is what exactly the patent covers and what the
implications of having the current kernel code are.

 - R.

[PATCH 1/5] remove TxStartThresh and RxEarlyThresh

[Jesse Huang]

From: Jesse Huang <jesse@icplus.com.tw>

Change Logs:
For pattern issue need to remove TxStartThresh and RxEarlyThresh.

Signed-off-by: Jesse Huang <jesse@icplus.com.tw>
---

 drivers/net/sundance.c |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

3751714e0fc36905c87a230172d9561c29321833
diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
index 6b8f4ba..a5dd1c3 100755
--- a/drivers/net/sundance.c
+++ b/drivers/net/sundance.c
@@ -264,8 +264,6 @@ enum alta_offsets {
 	ASICCtrl = 0x30,
 	EEData = 0x34,
 	EECtrl = 0x36,
-	TxStartThresh = 0x3c,
-	RxEarlyThresh = 0x3e,
 	FlashAddr = 0x40,
 	FlashData = 0x44,
 	TxStatus = 0x46,
@@ -1111,6 +1109,7 @@ static irqreturn_t intr_handler(int irq,
 	int tx_cnt;
 	int tx_status;
 	int handled = 0;
+	int i;
 
 
 	do {
@@ -1153,17 +1152,14 @@ static irqreturn_t intr_handler(int irq,
 						np->stats.tx_fifo_errors++;
 					if (tx_status & 0x02)
 						np->stats.tx_window_errors++;
+
 					/*
 					** This reset has been verified on
 					** DFE-580TX boards ! phdm@macqel.be.
 					*/
 					if (tx_status & 0x10) {	/* TxUnderrun */
-						unsigned short txthreshold;
-
-						txthreshold = ioread16 (ioaddr + TxStartThresh);
 						/* Restart Tx FIFO and transmitter */
 						sundance_reset(dev, (NetworkReset|FIFOReset|TxReset) << 16);
-						iowrite16 (txthreshold, ioaddr + TxStartThresh);
 						/* No need to reset the Tx pointer here */
 					}
 					/* Restart the Tx. */
-- 
1.3.GIT

[PATCH 1/5] remove TxStartThresh and RxEarlyThresh

[Jesse Huang]

From: Jesse Huang <jesse@icplus.com.tw>

Change Logs:
For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent 
is cut-through patent. If use this function, Tx will start to transmit after 
few data be move in to Tx FIFO. We are not allow to use those function in 
DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little 
performance.

Signed-off-by: Jesse Huang <jesse@icplus.com.tw>
---

 drivers/net/sundance.c |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

3751714e0fc36905c87a230172d9561c29321833
diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
index 6b8f4ba..a5dd1c3 100755
--- a/drivers/net/sundance.c
+++ b/drivers/net/sundance.c
@@ -264,8 +264,6 @@ enum alta_offsets {
 	ASICCtrl = 0x30,
 	EEData = 0x34,
 	EECtrl = 0x36,
-	TxStartThresh = 0x3c,
-	RxEarlyThresh = 0x3e,
 	FlashAddr = 0x40,
 	FlashData = 0x44,
 	TxStatus = 0x46,
@@ -1111,6 +1109,7 @@ static irqreturn_t intr_handler(int irq,
 	int tx_cnt;
 	int tx_status;
 	int handled = 0;
+	int i;
 
 
 	do {
@@ -1153,17 +1152,14 @@ static irqreturn_t intr_handler(int irq,
 						np->stats.tx_fifo_errors++;
 					if (tx_status & 0x02)
 						np->stats.tx_window_errors++;
+
 					/*
 					** This reset has been verified on
 					** DFE-580TX boards ! phdm@macqel.be.
 					*/
 					if (tx_status & 0x10) {	/* TxUnderrun */
-						unsigned short txthreshold;
-
-						txthreshold = ioread16 (ioaddr + TxStartThresh);
 						/* Restart Tx FIFO and transmitter */
 						sundance_reset(dev, (NetworkReset|FIFOReset|TxReset) << 16);
-						iowrite16 (txthreshold, ioaddr + TxStartThresh);
 						/* No need to reset the Tx pointer here */
 					}
 					/* Restart the Tx. */
-- 
1.3.GIT

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

[Benjamin Herrenschmidt]

On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
> From: Jesse Huang <jesse@icplus.com.tw>
> 
> Change Logs:
> For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent 
> is cut-through patent. If use this function, Tx will start to transmit after 
> few data be move in to Tx FIFO. We are not allow to use those function in 
> DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little 
> performance.

Somebody patented FIFO thresholds ? Gack ?

Ben.

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

[Alan Cox]

Ar Llu, 2006-10-16 am 07:26 +1000, ysgrifennodd Benjamin Herrenschmidt:
> On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
> > From: Jesse Huang <jesse@icplus.com.tw>
> > 
> > Change Logs:
> > For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent 
> > is cut-through patent. If use this function, Tx will start to transmit after 
> > few data be move in to Tx FIFO. We are not allow to use those function in 
> > DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little 
> > performance.
> 
> Somebody patented FIFO thresholds ? Gack ?

3COM hold several patents on certain kinds of early interrupt/early
start for network FIFOs. At least historically they also had a GPL Linux
driver that didn't use that feature on their own cards which I'm told
was fear of patent "leakage"

Alan

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

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

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...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]