RFC: Enabling ethernet drivers to return FCS in the skb?

Ethereal now has the ability to decode (and check) the FCS for ethernet frames (assuming it understands the protocol so it can determine that the last 4 bytes are FCS).

Is there any interest in adding an Ethtool command to tell the driver to push the extra 4 bytes of CSUM into the skb?

When enabling this feature, I'd also like to allow drivers to receive frames with bad FCS as well. This could be a separate flag if desired, but if only good FCS will ever be passed up the stack, then having it in the skb does not really add new information. At least some hardware appears to support receiving bad FCS frames (e1000, evidently), but I am not sure how wide-spread this feature is...

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

[cut]

The Intel i82586 and i82596 and can be told to receive frames with a bad FCS. They can also be told to send a precomputed FCS rather than computing it on the fly. The i82596 and tulip can also transfer the FCS to memory when receiving frames. I guess all of this is also supported on the i82557/8/9.

Regards,
Rask Ingemann Lambertsen

FYI, all DEC FDDI controllers we currently support (or support is being
worked on) do support receiving bad frames -- all frames are always passed to the rx path and it's up to a driver to decide if a bad frame should be completely discarded or other actions should be taken. By specification the boards also support sending frames with a manually calculated checksum, which may possibly be intentionally wrong, but I haven't actually tested it.

If such functionality is added for Ethernet boards, I'm willing to
support it for these DEC FDDI boards as well.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email protected], PGP key available        +

If you have a patch or example code that shows how to do this, I'd love to see it. I have code that should RX bad CSUM from the Intel folks, but I can't get it to generate bad CRC (it does framing errors instead with my attempt), so I can't test the RX code properly!

I have the path from user-space to the NIC written, so just need to tweak the drivers a bit...

Do you know if tulip can be told to accept bad FCS and/or if it can generate a frame with bad FCS somehow?

Thanks!
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

The i825xx Ethernet chips are configured by putting a configure command on the TX list. One of the bits of the configure command tells the chip to discard or keep packets with errors. Assuming you can find that piece of code, flipping the bit is easy enough. Similiarily for transferring the FCS to/from memory. IIRC, this is a per-frame setting for TX on i82596 and i82557/8/9. You can find i82596 documentation on Intel's home page and the i82557/8/9 on SourceForge under the e100 (or was it e1000?) project.

You will still need to hack the RX code to not discard frames with the error flag set.

I don't have any code to show for it.

Please note that error counters displayed by "ifconfig" and "netstat -i" are based on /proc/net/dev (or so), which is a munged version of dev->get_stats(). Use "ip -s -s link show" to get the real values (and correctly labelled too). And even then, some drivers may not maintain the statistics properly.

Indeed, since currently drivers are assumed to strip the FCS on RX and insert it on TX. There is no defined way of telling the drivers that the FCS should be in the skb.

No. I don't know much about the tulip. But here is what I do know:
1) The FCS is transferred to memory right after the frame data. If you disable the rx_copy_break, then you'll find it in the skb (at skb->tail).
2) The maximum frame size, all included, is 2047 bytes, because of the descriptor format. Some "jumbo" frame, eh?
3) Frames larger than 1514 bytes (not including the FCS) are flagged as errored, even when otherwise perfectly fine, and passed to the host. With a bit of luck, the tulip will pass you frames with a bad FCS too.
4) The transmitter stops working after a few frames if the MTU is larger than about 2014 bytes.

You can hack the RX path to mung the error bits before testing them. Like so (this is my experimental VLAN/jumbo frame hack for the de2104x driver):

@@ -19,7 +19,6 @@
 	  like dl2k.c/sundance.c
 	* Constants (module parms?) for Rx work limit
 	* Complete reset on PciErr
-	* Jumbo frames / dev->change_mtu
 	* Adjust Rx FIFO threshold and Max Rx DMA burst on Rx FIFO error
 	* Adjust Tx FIFO threshold and Max Tx DMA burst on Tx FIFO error
 	* Implement Tx software interrupt mitigation via

@@ -36,6 +35,7 @@
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
+#include <linux/if_vlan.h>
 #include <linux/init.h>
 #include <linux/pci.h>
 #include <linux/delay.h>

@@ -94,6 +100,7 @@
 	  (CP)->tx_tail + (DE_TX_RING_SIZE - 1) - (CP)->tx_head :	\
 	  (CP)->tx_tail - (CP)->tx_head - 1)
 
+#define PKT_BUF_SZ_MAX		2047	/* Maximum Rx buffer size. */
 #define PKT_BUF_SZ		1536	/* Size of each temporary Rx buffer.*/
 #define RX_OFFSET		2
 

@@ -403,7 +410,7 @@
 	int rc;
 
 	while (rx_work--) {
-		u32 status, len;
+		u32 status, len, status_hacked;
 		dma_addr_t mapping;
 		struct sk_buff *skb, *copy_skb;
 		unsigned copying_skb, buflen;

@@ -424,7 +431,13 @@
 			goto rx_next;
 		}
 
-		if (unlikely((status & 0x38008300) != 0x0300)) {
+		/* Ugly Jumbo frame hack. Remove error flag on long frames. */
+		if ((status & (RxErrLong | RxErrCRC | RxErrFIFO | RxErrRunt | RxErrFrame)) == RxErrLong)
+			status_hacked = status & ~(RxError | RxErrLong);
+		else
+			status_hacked = status;
+
+		if (unlikely((status_hacked & 0x38008300) != 0x0300)) {
 			de_rx_err_acct(de, rx_tail, status, len);
 			goto rx_next;
 		}

@@ -1372,6 +1390,8 @@
 		printk(KERN_DEBUG "%s: enabling interface\n", dev->name);
 
 	de->rx_buf_sz = (dev->mtu <= 1500 ? PKT_BUF_SZ : dev->mtu + 32);
+	if (de->rx_buf_sz > PKT_BUF_SZ_MAX)
+		de->rx_buf_sz = PKT_BUF_SZ_MAX;
 
 	rc = de_alloc_rings(de);
 	if (rc) {

@@ -1464,6 +1482,18 @@
 	netif_wake_queue(dev);
 }
 
+static int de_change_mtu (struct net_device *dev, int mtu)
+{
+	if (netif_running (dev))
+		return (-EBUSY);
+	
+	if (mtu < 0 || mtu > PKT_BUF_SZ_MAX - VLAN_ETH_HLEN - 4)
+		return (-EINVAL);
+
+	dev->mtu = mtu;
+	return (0);
+}
+
 static void __de_get_regs(struct de_private *de, u8 *buf)
 {
 	int i;

@@ -1964,6 +1994,7 @@
 	dev->ethtool_ops = &de_ethtool_ops;
 	dev->tx_timeout = de_tx_timeout;
 	dev->watchdog_timeo = TX_TIMEOUT;
+	dev->change_mtu = de_change_mtu;
 
 	dev->irq = pdev->irq;
 

I saw a link to the tulip documentation somewhere, but I neither bookmarked the URL nor downloaded the documentation. :-(

Regards,
Rask Ingemann Lambertsen

Thanks, I found the e100 document (from sourceforge) and it looks like it can definately receive all sorts of busted packets with a little configuration.

It's less clear what happens when you turn off the FCS generation. One part of the document mentions it gets it from RAM, which I assume means it uses the last part of the DMA'd packet??? Another explanation of the transmit state machine does not mention that you can disable FCS generation... I'm going to print this out and read it again in detail...

I searched Intel's site for the e1000 docs, but could not find any detailed information. Does anyone have a link to a (legal) copy of the e1000 docs?

Thanks for the detailed information. When I get the e100 and e1000 working to my satisfaction, I'll work on the tulip driver a bit.

Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

On Sun, Nov 23, 2003 at 01:02:41AM -0800, Ben Greear wrote:

[Intel i82557/8/9 Ethernet chips]

Saving bad frames to memory is controlled by CB_CFIG_SAVE_BAD_FRAMES in byte
6. Saving the FCS to memory is controlled by CB_CFIG_CRC_IN_MEM in byte 18. See drivers/net/e100/e100_config.h.

Yes. The last four octets from the skb will be interpreted as an FCS by whichever board receives that frame.

There is a bit in the command word of a TX command which disables FCS generation. I can't find that bit defined in drivers/net/e100/e100.h, so you'll have to find it in the docs.

Regards,
Rask Ingemann Lambertsen