What’s needed to receive? A look at the minimum steps required for programming our 82573L nic to receive packets.

Slides:



Advertisements
Similar presentations
The Journey of a Packet Through the Linux Network Stack
Advertisements

© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public ITE PC v4.0 Chapter 1 1 Addressing the Network – IPv4 Network Fundamentals – Chapter 6.
Internet Control Protocols Savera Tanwir. Internet Control Protocols ICMP ARP RARP DHCP.
Hardware ‘flow control’ How we can activate our NIC’s ability to avoid overwhelming the capacities of its ‘link partner’
Utilizing NIC’s enhancements A look at how driver software needs to change when using newer features of our hardware.
Dr A Sahu Dept of Comp Sc & Engg. IIT Guwahati. PCI Devices NIC Cards NIC card architecture Access to NIC register – PCI access.
More 82573L details Getting ready to write and test a character-mode device-driver for our anchor-LAN’s ethernet controllers.
Receiver ‘packet-splitting’
Virtual Local Area Networks A look at how the Intel 82573L nic supports IEEE standard 802.1q for ethernet VLANs.
1 Fall 2005 Hardware Addressing and Frame Identification Qutaibah Malluhi CSE Department Qatar University.
The RealTek interface Introduction to the RTL-8139 network controller registers.
A look at memory issues Data-transfers must occur between system memory and the network interface controller.
CCNA 3 v3.1 Module 4.
Exploring a modern NIC An introduction to programming the Intel 82573L gigabit ethernet network interface controller.
82573L Initializing our Pro/1000. Chicken-and-Egg? We want to create a Linux Kernel Module that can serve application-programs as a character-mode device-driver.
RTL-8139 experimentation Setting up an environment for studying the Network Controller.
Examining network packets Information about the RTL8139 needed for understanding our ‘watch235.c’ pseudo driver.
Our ‘recv1000.c’ driver Implementing a ‘packet-receive’ capability with the Intel 82573L network interface controller.
t Popularity of the Internet t Provides universal interconnection between individual groups that use different hardware suited for their needs t Based.
The hardware ringbuffer Understanding the RTL-8139 mechanism for packet reception.
Our ‘nic.c’ module We create a ‘character-mode’ device-driver for the 82573L NIC to use in futrure experiments.
Our ‘nic.c’ module We create a ‘character-mode’ device-driver for the 82573L NIC to use in future experiments.
What’s needed to transmit? A look at the minimum steps required for programming our 82573L nic to send packets.
What’s needed to transmit? A look at the minimum steps required for programming our anchor nic’s to send packets.
Hardware-address filtering How can we send packets to just one node on our ‘anchor’ cluster?
What’s needed to receive? A look at the minimum steps required for programming our anchor nic’s to receive packets.
IP Address 0 network host 10 network host 110 networkhost 1110 multicast address A B C D class to to
1 K. Salah Module 4.3: Repeaters, Bridges, & Switches Repeater Hub NIC Bridges Switches VLANs GbE.
Layer 2 Switch  Layer 2 Switching is hardware based.  Uses the host's Media Access Control (MAC) address.  Uses Application Specific Integrated Circuits.
Chapter 4 Queuing, Datagrams, and Addressing
SUSE Linux Enterprise Server Administration (Course 3037) Chapter 7 Connect the SUSE Linux Enterprise Server to the Network.
Input/Output. Input/Output Problems Wide variety of peripherals —Delivering different amounts of data —At different speeds —In different formats All slower.
Introduction 1 Lecture 23 Link Layer (Error Detection/Correction) slides are modified from J. Kurose & K. Ross University of Nevada – Reno Computer Science.
5: DataLink Layer5-1 Chapter 5 Link Layer and LANs Part 1: Overview of the Data Link layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose,
TELE202 Lecture 10 Internet Protocols (2) 1 Lecturer Dr Z. Huang Overview ¥Last Lecture »Internet Protocols (1) »Source: chapter 15 ¥This Lecture »Internet.
Internet Protocol (IP)
Chapter 1-3 The Ethernet LAN. Ethernet The networking protocol used in most modern computer networks is Ethernet. Ethernet is a CSMA/CD LAN protocol.
Brierley 1 Module 4 Module 4 Introduction to LAN Switching.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Principles of I/0 hardware.
CMPT 471 Networking II Address Resolution IPv4 ARP RARP 1© Janice Regan, 2012.
S3C2 – LAN Switching Addressing LAN Problems. Congestion is Caused By Multitasking, Faster operating systems, More Web-based applications Client-Server.
Hyung-Min Lee ©Networking Lab., 2001 Chapter 8 ARP and RARP.
11 NETWORK CONNECTION HARDWARE Chapter 3. Chapter 3: NETWORK CONNECTION HARDWARE2 NETWORK INTERFACE ADAPTER  Provides the link between a computer and.
Ethernet Driver Changes for NET+OS V5.1. Design Changes Resides in bsp\devices\ethernet directory. Source code broken into more C files. Native driver.
NS Training Hardware.
1 © 2003, Cisco Systems, Inc. All rights reserved. CCNA 3 v3.0 Module 4 Switching Concepts.
1 Network Administration Module 3 ARP/RARP. 2 Address Resolution The problem Physical networks use physical addresses, not IP addresses Need the physical.
Cisco 3 - Switching Perrine. J Page 16/4/2016 Chapter 4 Switches The performance of shared-medium Ethernet is affected by several factors: data frame broadcast.
Chapter 9 Hardware Addressing and Frame Type Identification 1.Delivering and sending packets 2.Hardware addressing: specifying a destination 3. Broadcasting.
1 Ch 9 Hardware Addressing and Frame Type Identification.
Chapter 5 Link Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Link Layer introduction,
STORE AND FORWARD & CUT THROUGH FORWARD Switches can use different forwarding techniques— two of these are store-and-forward switching and cut-through.
EC week Review. Rules of Engagement Teams selected by instructor Host will read the entire questions. Only after, a team may “buzz” by raise of.
Linux Operations and Administration Chapter Eight Network Communications.
Input/Output Problems Wide variety of peripherals —Delivering different amounts of data —At different speeds —In different formats All slower than CPU.
Chapter 7 OSI Data Link Layer.
1 Hardware Addressing and Frame Type Identification.
CCNA3 Module 4 Brierley Module 4. CCNA3 Module 4 Brierley Topics LAN congestion and its effect on network performance Advantages of LAN segmentation in.
Introduction to Ethernet In 1985, the Institute of Electrical and Electronics Engineers (IEEE) published standards for LANs. These standards start with.
+ Lecture#2: Ethernet Asma ALOsaimi. + Objectives In this chapter, you will learn to: Describe the operation of the Ethernet sublayers. Identify the major.
WINLAB Open Cognitive Radio Platform Architecture v1.0 WINLAB – Rutgers University Date : July 27th 2009 Authors : Prasanthi Maddala,
Introduction to Networks v6.0
Instructor Materials Chapter 5: Ethernet
Local Area Networks: Topologies
Net 323: NETWORK Protocols
Internet Protocol (IP)
Operating Systems Chapter 5: Input/Output Management
Protocol layering and data
Protocol layering and data
Presentation transcript:

What’s needed to receive? A look at the minimum steps required for programming our 82573L nic to receive packets

Accessing 82573L registers Device registers are hardware mapped to a range of addresses in physical memory We can get the location and extent of this memory-range from a BAR register in the 82573L device’s PCI Configuration Space We then request the Linux kernel to setup an I/O ‘remapping’ of this memory-range to ‘virtual’ addresses within kernel-space

kernel space Linux address-spaces dynamic ram nic registers user space kernel code/data nic registers ‘virtual’ address-spacephysical address-space 128-TB.text,.data,.bss stack shared libraries dynamic ram 64-GB

Kernel memory allocation The NIC requires that some host memory for packet-buffers and receive descriptors The kernel provides a ‘helper function’ for reserving a suitable region of memory in kernel-space which is both ‘non-pageable’ and ‘physically contiguous’ (i.e., kzalloc()) It’s our job is to decide how much memory our network controller hardware will need

Format for an Rx Descriptor Base-address (64-bits) status Packet- length Packet- checksum VLAN tag errors 16 bytes The device-driver initializes this ‘base-address’ field with the physical address of a packet-buffer The network controller will ‘write-back’ the values for these fields when it has transferred a received packet’s data into this descriptor’s packet-buffer

Suggested C syntax typedef struct{ unsigned long longbase_address; unsigned shortpacket_length; unsigned shortpacket_cksum; unsigned chardesc_status; unsigned chardesc_errors; unsigned shortvlan_tag; } RX_DESCRIPTOR; ‘Legacy Format’ for the Intel Pro1000 network controller’s Receive Descriptors

the packet’s data ‘payload’ goes here (usually varies from 56 to 1500 bytes) Ethernet packet layout Total size normally can vary from 64 bytes up to 1522 bytes (unless ‘jumbo’ packets and/or ‘undersized’ packets are enabled) The NIC expects a 14-byte packet ‘header’ and it appends a 4-byte CRC check-sum destination MAC address (6-bytes) source MAC address (6-bytes) Type/length (2-bytes) Cyclic Redundancy Checksum (4-bytes)

Rx-Descriptor Ring-Buffer Circular buffer (128-bytes minimum – and must be a multiple of 128 bytes) RDBA base-address RDLEN (in bytes) RDH (head) RDT (tail) = owned by hardware (nic) = owned by software (cpu) 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80

Packet-buffers and descriptors Our ‘nicrx.c’ module allocates 8 buffers of size 2K-bytes (i.e., more than enough for any normal Ethernet packets) 16K bytes allocated (8 packet-buffers, plus Rx-Descriptor Queue) for the Rx Descriptor Queue (128 bytes) for the eight packet-buffers

RxDesc Status-field PIFIPCSTCPCSVPIXSMEOPDD 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 UDPCS

RxDesc Error-field RXEIPETCPE reserved =0 SECE RXE = Received-data Error (1=yes, 0=no) IPE = IPv4-checksum error TCPE = TCP/UDP checksum error (1=yes, 0=no) SEQ = Sequence error (1=yes, 0=no) SE = Symbol Error (1=yes, 0=no) CE = CRC Error or alignment error (1=yes, 0=no) SEQ reserved =0

Essential ‘receive’ registers enum{ E1000_CTRL0x0000,// Device Control E1000_STATUS0x0008,// Device Status E1000_RCRL0x0100,// Receive Control E1000_RDBAL0x2800,// Rx Descriptor Base Address Low E1000_RDBAH0x2804,// Rx Descriptor Base Address High E1000_RDLEN0x2808,// Rx Descriptor Length E1000_RDH0x2810,// Rx Descriptor Head E1000_RDT0X2818,// Rx Descriptor Tail E1000_RXDCTL0x2828,// Rx Descriptor Control E1000_RA0x5400,// Receive address-filter Array };

Programming steps 1)Detect the presence of the 82573L network controller (VENDOR_ID, DEVICE_ID) 2)Obtain the physical address-range where the nic’s device-registers are mapped 3)Ask the kernel to map this address range into the kernel’s virtual address-space 4)Copy the network controller’s MAC-address into a 6-byte array for future access 5)Allocate a block of kernel memory large enough for our descriptors and buffers 6)Insure that the network controller’s ‘Bus Master’ capability has been enabled 7)Select our desired configuration-options for the DEVICE CONTROL register 8)Perform a nic ‘reset’ operation (by toggling bit 26), then delay until reset completes 9)Select our desired configuration-options for the RECEIVE CONTROL register 10)Initialize our array of Receive Descriptors with the physical addresses of buffers 11)Initialize the Receive Engine’s registers (for Rx-Descriptor Queue and Control) 12)Give ‘ownership’ of all of our Rx-Descriptors to the network controller 13)Enable the Receive Engine 14)Install our ‘/proc/nicrx’ pseudo-file (for user-diagnostic purposes) NOTE: Steps 1) through 8) are the same as for our ‘nictx.c’ kernel module.

Device Control (0x0000) PHY RST VME R =0 TFCERFCE RST R =0 R =0 R =0 R =0 R =0 ADV D3 WUC R =0 D/UD status R =0 R =0 R =0 R =0 R =0 FRC DPLX FRC SPD R =0 SPEED R =0 SLUSLU R =0 R =0 R =1 0 FDFD GIO M D R = FD = Full-DuplexSPEED (00=10Mbps, 01=100Mbps, 10=1000Mbps, 11=reserved) GIOMD = GIO Master DisableADVD3WUP = Advertise Cold Wake Up Capability SLU = Set Link UpD/UD = Dock/Undock statusRFCE = Rx Flow-Control Enable FRCSPD = Force SpeedRST = Device ResetTFCE = Tx Flow-Control Enable FRCDPLX = Force DuplexPHYRST = Phy ResetVME = VLAN Mode Enable 82573LWe used 0x04000A49 to initiate a ‘device reset’ operation

0 Device Status (0x0008) ? GIO Master EN PHY RA ASDV ILOSILOS SLUSLU 0 TX OFF 0 FDFD Function ID LULU SPEED FD = Full-Duplex LU = Link Up TXOFF = Transmission Paused SPEED (00=10Mbps,01=100Mbps, 10=1000Mbps, 11=reserved) ASDV = Auto-negotiation Speed Detection Value PHYRA = PHY Reset Asserted 82573L some undocumented functionality?

Receive Control (0x0100) R =0 00 FLXBUF SE CRC BSEX R =0 PMCF DPF R =0 CFI EN VFE BSIZE BAMBAM R =0 MODTYPRDMTS ILOSILOS SLUSLU LPEUPE 0 R = SBP ENEN LBMMPE EN = Receive Enable DTYP = Descriptor TypeDPF = Discard Pause Frames SBP = Store Bad Packets MO = Multicast OffsetPMCF = Pass MAC Control Frames UPE = Unicast Promiscuous Enable BAM = Broadcast Accept ModeBSEX = Buffer Size Extension MPE = Multicast Promiscuous Enable BSIZE = Receive Buffer SizeSECRC = Strip Ethernet CRC LPE = Long Packet reception Enable VFE = VLAN Filter EnableFLXBUF = Flexible Buffer size LBM = Loopback ModeCFIEN = Canonical Form Indicator Enable RDMTS = Rx-Descriptor Minimum Threshold SizeCFI = Canonical Form Indicator bit-value We used 0x C in RCTL to prepare the ‘receive engine’ prior to enabling it

Rx-Descriptor Control (0x2828) GRANGRAN 00 WTHRESH (Writeback Threshold) 000 FRC DPLX FRC SPD 0 HTHRESH (Host Threshold) ILOSILOS 0 ASDEASDE 0 LRSTLRST PTHRESH (Prefetch Threshold) 00 Recommended for 82573: 0x (GRAN=1, WTHRESH=1) “This register controls the fetching and write back of receive descriptors. The three threshold values are used to determine when descriptors are read from, and written to, host memory. Their values can be in units of cache lines or of descriptors (each descriptor is 16 bytes), based on the value of the GRAN bit (0=cache lines, 1=descriptors). When GRAN = 1, all descriptors are written back (even if not requested).” --Intel manual

PCI Bus Master DMA 82573L i/o-memory RX and TX FIFOs (32-KB total) Host’s Dynamic Random Access Memory Descriptor Queue packet-buffer DMA on-chip RX descriptors on-chip TX descriptors

Pthresh and Hthresh When the number of unprocessed descriptors in the NIC’s on-chip memory has fallen below the Prefetch Threshold, and the number of valid descriptors in host memory which are owned by the NIC is at least equal to the Host Threshold, then the NIC will fetch that number of descriptors in a single ‘burst’ DMA-transfer

Wthresh When the number of descriptors waiting in the NIC’s on-chip memory to be written back to Host memory is at least equal to the Writeback Thrershold, then the NIC will write back that number of descriptors in a single ‘burst’ DMA-transfer

Experiment #1 Let’s install our ‘nicrx.c’ kernel module on one host, and use the ‘cat’ command to view its queue of Rx-Descriptors: $ /sbin/insmod nicrx.ko $ cat /proc/nicrx Then let’s install our ‘nictx.c’ module on a different host on the same local network: $ /sbin/insmod nictx.ko Now look again at the receive descriptors!

Experiment #2 Install our ‘dram.c’ device-driver module on both of these host-machines, and use our ‘fileview’ utility to look at the contents of each module’s packet-buffers – you’ll find their physical addresses displayed if you use ‘cat’ to see the descriptor-queues: $ cat /proc/nictxand$ cat /proc/nicrx

Experiment #3 Our ‘nicrx.c’ module had enabled both the Unicast and Multicast promiscuous modes So let’s watch what happens when we use the ‘/sbin/ifconfig’ command (with ‘sudo’) to bring up a secondary network interface on another host on the same segment of our local network Do you recognize these new packets?

Experiment #4 With ‘nicrx.c’ module installed on one host, log on to two other hosts on the same LAN and bring up their ‘eth1’ network interfaces Use the ‘ping’ command on one of these two hosts to try contacting the other one What do you observe about any packets that are received by the host where our ‘nicrx.c’ module had been installed?

In-class exercise Suppose you turn off the UPE-bit (bit #3) in the Receive Control register (in nicrx.c) From another host on the same segment, bring up its ‘eth1’ interface, then adjust its routing table so that all multicast packets are sent out via the secondary interface: $ sudo /sbin/route add –net netmask device eth1 If you ‘ping’ a multicast address, will the ICMP datagram be received by ‘nicrx.c’?