Ethernet CRC questions

Ethernet CRC questions

[thomas yang]

How does Linux  generate Ethernet CRC ?
by the hardware (Ethernet controller)  or  use crc32_le() /
crc32_be()     ( lib/crc32.c )  ?

P.S.   my  network card is  rtl8139d  , use  8139too driver


--
thomas

Re: Ethernet CRC questions

[Ben Hutchings]

On Wed, 2009-12-30 at 01:17 +0800, thomas yang wrote:
> How does Linux  generate Ethernet CRC ?
> by the hardware (Ethernet controller)  or  use crc32_le() /
> crc32_be()     ( lib/crc32.c )  ?
> 
> P.S.   my  network card is  rtl8139d  , use  8139too driver

The Ethernet frame CRC is normally generated and verified in hardware.
These library functions are needed for the few MACs that don't, or where
the same CRC function is used for some other purpose (e.g. as a hash
function for multicast filtering).

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: Ethernet CRC questions

[thomas yang]

2009/12/30 Ben Hutchings <bhutchings@solarflare.com>:
> On Wed, 2009-12-30 at 01:17 +0800, thomas yang wrote:
>> How does Linux  generate Ethernet CRC ?
>> by the hardware (Ethernet controller)  or  use crc32_le() /
>> crc32_be()     ( lib/crc32.c )  ?
>>
>> P.S.   my  network card is  rtl8139d  , use  8139too driver
>
> The Ethernet frame CRC is normally generated and verified in hardware.
> These library functions are needed for the few MACs that don't, or where
> the same CRC function is used for some other purpose (e.g. as a hash
> function for multicast filtering).
>

Does the Ethernet frame CRC (generate and verify in hardware)  make
the TX / RX  rate  a little smaller , and a longer end-to-end  delay ?
 Could I disable CRC appending / verifying  in the network card driver
  on all of my nodes (machines) ?

Thanks.



--
Thomas

Re: Ethernet CRC questions

[Matti Aarnio]

On Wed, Dec 30, 2009 at 01:53:09PM +0800, thomas yang wrote:
> 2009/12/30 Ben Hutchings <bhutchings@solarflare.com>:
> > On Wed, 2009-12-30 at 01:17 +0800, thomas yang wrote:
> >> How does Linux  generate Ethernet CRC ?
> >> by the hardware (Ethernet controller)  or  use crc32_le() /
> >> crc32_be()     ( lib/crc32.c )  ?
> >>
> >> P.S.   my  network card is  rtl8139d  , use  8139too driver
> >
> > The Ethernet frame CRC is normally generated and verified in hardware.
> > These library functions are needed for the few MACs that don't, or where
> > the same CRC function is used for some other purpose (e.g. as a hash
> > function for multicast filtering).
> 
> Does the Ethernet frame CRC (generate and verify in hardware)  make
> the TX / RX  rate  a little smaller , and a longer end-to-end  delay ?
>  Could I disable CRC appending / verifying  in the network card driver
>   on all of my nodes (machines) ?

You would need to similarly disable the checking and generating at your
network switches as well.  It really is not worthwhile.

You are better to use multiple links in between the machines in parallel,
and bond them together as load-sharing link.  Or go to 10G.
(We used to do that kind of things with quad fast-ethernet cards, but
with gigaethers we did not bother anymore.)

> Thanks.

Best Regards,  Matti Aarnio

Re: Ethernet CRC questions

[Ben Hutchings]

On Wed, 2009-12-30 at 13:53 +0800, thomas yang wrote:
> 2009/12/30 Ben Hutchings <bhutchings@solarflare.com>:
> > On Wed, 2009-12-30 at 01:17 +0800, thomas yang wrote:
> >> How does Linux  generate Ethernet CRC ?
> >> by the hardware (Ethernet controller)  or  use crc32_le() /
> >> crc32_be()     ( lib/crc32.c )  ?
> >>
> >> P.S.   my  network card is  rtl8139d  , use  8139too driver
> >
> > The Ethernet frame CRC is normally generated and verified in hardware.
> > These library functions are needed for the few MACs that don't, or where
> > the same CRC function is used for some other purpose (e.g. as a hash
> > function for multicast filtering).
> >
> 
> Does the Ethernet frame CRC (generate and verify in hardware)  make
> the TX / RX  rate  a little smaller , and a longer end-to-end  delay ?

Relative to what?

>  Could I disable CRC appending / verifying  in the network card driver
>   on all of my nodes (machines) ?

Maybe if you want switches to discard everything you send...

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: Ethernet CRC questions

[thomas yang]

>>
>> Does the Ethernet frame CRC (generate and verify in hardware)  make
>> the TX / RX  rate  a little smaller , and a longer end-to-end  delay ?
>
> Relative to what?
>

Relative to the Ethernet frame without CRC appending / verifying .


In IEEE 802.3 standard, all network devices should append/verify CRC?

>>  Could I disable CRC appending / verifying  in the network card driver
>>   on all of my nodes (machines) ?
>
> Maybe if you want switches to discard everything you send...
>

So, I should disable CRC appending / verifying on all kinds of network
devices in my network?
In this way I will  TX/RX packets more faster ?


--
Thomas

Re: Ethernet CRC questions

[Ben Hutchings]

On Thu, 2009-12-31 at 00:19 +0800, thomas yang wrote:
> >>
> >> Does the Ethernet frame CRC (generate and verify in hardware)  make
> >> the TX / RX  rate  a little smaller , and a longer end-to-end  delay ?
> >
> > Relative to what?
> >
> 
> Relative to the Ethernet frame without CRC appending / verifying .
> 
> 
> In IEEE 802.3 standard, all network devices should append/verify CRC?

Not 'should' but 'must'.

> >>  Could I disable CRC appending / verifying  in the network card driver
> >>   on all of my nodes (machines) ?
> >
> > Maybe if you want switches to discard everything you send...
> >
> 
> So, I should disable CRC appending / verifying on all kinds of network
> devices in my network?
> In this way I will  TX/RX packets more faster ?

You will probably not be able to disable CRC validation on switches
because it is not a sensible thing to do.  So if you disable CRC
generation on NICs then your network will notwork.

Really, 32 bit-times is not much to worry about (only 320 ns even at
100M).  There are likely to be much bigger sources of latency to attack.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.