Utilizing NIC’s enhancements‘theory’ versus ‘practice’‘backward compatibility’Example: Intel’s x86Gigabit NICs‘Legacy’ RX-DescriptorsSlide 7Slide 8‘Extended’ RX-DescriptorsSlide 10Extended Rx-Status (20-bits)Extended Rx-Errors (12 bits)Main device-driver changesUse of C language ‘union’‘Bitfields’ in CSyntax for Rx-DescriptorsRFCTL (0x5008)Modifying ‘my_read()’For our pseudo-file’s sake…OK, but then when?Handling ‘RXDMT0’ interrupts‘extended.c’Demo: ‘bitfield.c’Utilizing NIC’s enhancementsA look at how driver software needs to change when using newer features of our hardware‘theory’ versus ‘practice’•The engineering designs one encounters in computer hardware components can be observed to undergo an ‘evolution’ during successive iterations, from a scheme that embodies simplicity, purity, and symmetry at the outset, based upon what designers think will be the device’s likely uses, to a conglomeration of disparate ‘add-ons’ as actual practices dictate accommodations‘backward compatibility’•An historically important consideration in the marketing of computer hardware has been the need to maintain past functions in a ‘transparent’ manner – i.e., no change is needed to run older software on newer equipment, while offering enhancements as ‘options’ that can be selectively enabledExample: Intel’s x86•The current generation of Intel CPU’s will still execute all of the software written for PCs a quarter-century ago – based on a small set of 16-bit registers, a restricted set of instructions, and a one-megabyte memory-space – but is able, as an option, to use more and larger registers (64-bits), richer instruction-sets, and more memoryGigabit NICs•Intel’s network controller designs exhibit this same kind of ‘evolution’ over time•The ‘Legacy’ descriptor-formats are just one example of keeping prior-generation functionality: it’s simple, it’s ‘pure’ (i.e., not tied to any specific network-protocols, but emphasizing ‘mechanism’, not ‘policy’) •But now alternatives exist -- as options!‘Legacy’ RX-DescriptorsBase-address (64-bits)statusPacket-lengthPacket-checksumVLANtagerrorsThe device-driver initializes this ‘base-address’ field with the physical address of a packet-buffer… … and network hardware does not ever modify it The network controller later will ‘write-back’ values into all these fields when it has finished transferring a received packet’s data into that packet-bufferRxDesc Status-fieldPIF IPCS TCPCS VP IXSM EOP DD7 6 5 4 3 2 1 0 DD = Descriptor Done (1=yes, 0=no) shows if nic is finished with descriptor EOP = End Of Packet (1=yes, 0=no) shows if this packet is logically last IXSM = Ignore Checksum Indications (1=yes, 0=no) VP = VLAN Packet match (1=yes, 0=no) USPCS = UDP Checksum calculated in packet (1=yes, 0=no) TCPCS = TCP Checksum calculated in packet (1=yes, 0=no) IPCS = IPv4 Checksum calculated on packet (1=yes, 0=no) PIF = Passed In-exact Filter (1=yes, 0=no) shows if software must check UDPCSRxDesc Errors-fieldRXE IPE TCPEreserved(=0)SEQ SE CE7 6 5 4 3 2 1 0 CE = CRC Error or Alignment Error (check statistics registers to differentiate) TCPE = TCP/UDP Checksum Error IPE = IPv4 Checksum Error These bits are relevant only while NIC is operating in ‘SerDes’ mode: SE = Symbol Error SEQ = Sequence Error RXE = Rx Data Errorreserved(=0)‘Extended’ RX-DescriptorsBase-address (64-bits)reserved (=0)MRQ(multiple receive queues)ExtendedstatusPacket-lengthPacket-checksumVLANtagExtendederrorsIPidentificationThe device-driver initializes the ‘base-address’ field with the physical address of a packet-buffer, and it initializes the ‘reserved’ field with a zero-value… … the network hardware will later modify both fields The network controller will ‘write-back’ the values for these fields when it has transferred a received packet’s data into the packet-bufferCPU writes this, NIC reads it: NIC writes this, CPU reads it:An alternative option Base-address (64-bits)reserved (=0)MRQ(multiple receive queues)ExtendedstatusPacket-lengthRSS Hash(Receive Side Scaling)VLANtagExtendederrorsCPU writes this, NIC reads it: NIC writes this, CPU reads it: ‘Receive Side Scaling’ refers to an optional capability in the network controller to assist with routing of network packets to various CPUs within a modern multiprocessor system(See Section 3.2.13 in Intel’s Software Developer’s Manual)Extended Rx-Status (20-bits)0 0 0 0ACK0 0 0 0UDPVIPIV0PIFIPCSTCPCSUDPCSVPIXSMEOPDD 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0These eight bits have the same meanings as in a ‘Legacy’ Rx-Status byte These ‘extra’ status-bits provide additional hardware support to driver software for processing ethernet packets that conform to standard TCP/IP network protocols (with possibilities for future expansion) DD = Descriptor Done EOP = End Of Packet IXSM = Ignore Checksum Indications VP = VLAN Packet match USPCS = UDP Checksum calculated TCPCS = TCP Checksum calculated IPCS = IPv4 Checksum calculated PIF = Passed In-exact Filter ACK = TCP ACK-Packet identificationUDPV = Valid UDP checksumIPIV = Valid IP IdentificationExtended Rx-Errors (12 bits)RXE IPE TCPE 0 0 SEQ SE CE 0 0 0 0 11 10 9 8 7 6 5 4 3 2 1 0These eight bits have the same meanings, and the occupy the same arrangement, as in the ‘Legacy’ Rx-Errors byteMain device-driver changes•If we want to utilize the NIC’s ‘Extended’ Receive Descriptor format, we will need several significant changes in our driver source-code and data-types:•Our module’s initialization of ‘base_address’ fields•Our new need for programming register RFCTL•Our ‘typedef’ for the ‘RX_DESCRIPTOR’ structs•Our ‘get_info_rx()’ function for ‘/proc/nicrx’ display•Our interrupt-handler’s treatment of ‘rxring’ entriesUse of C language ‘union’•Each Receive-Descriptor now has a ‘dual’ identity, as far as the NIC is concerned: –one layout during its ‘fetch’ from memory–another layout during ‘write-back’ to
View Full Document
Unlocking...