Analysis of VxWorks 6.6 Network Protocol Stack and Basic Knowledge of Network Interfaces

Click “Read the original text” to access more VxWorks resources

Free download of VxWorks technical materials, resources from the internet, copyright belongs to the original author!

This article includes the basic principles of hardware for network interfaces and the analysis of the VxWorks 6.6 network protocol stack/drivers, applicable to VxWorks 6.6 and earlier versions, and can be used as a reference for other version protocol stacks.

0. Overview

0.1 Network Interface

Currently, there are two models for Ethernet, namely the OSI seven-layer model defined by the ISO (International Organization for Standardization) and the TCP/IP five-layer model defined by the IETF (Internet Engineering Task Force), which can be referred to in detail in the TCP/IP protocol explanation. Currently, TCP/IP is the de facto standard for the internet, and the specific layers are as follows:

Analysis of VxWorks 6.6 Network Protocol Stack and Basic Knowledge of Network Interfaces

In the table above:

Ethernet Frame Format corresponds to the layers in the table above:

MAC, also known as the Ethernet controller, has an independent link layer address (MAC address, also known as the Ethernet address), which is usually referred to or narrowly defined as the network port, used to control the transmission of link layer data;
PHY is used to control physical layer transmission, for functions such as encoding and decoding data between the physical link and MAC, physical link control, carrier sensing, line sequence swapping, etc. It usually only includes PCS (Physical Coding Sublayer), PMD (Physical Medium Dependent Sublayer), PMA (Physical Medium Attachment Sublayer), etc., but high-speed links above 1000Mbps require more sublayers (DTE XGXS, PHY XGXS);
MAC connects to PHY through buses such as MII (narrowly defined as Media Independent Interface)/RGMII (Reduced Gigabit Media Independent Interface)/SGMII (Serial Gigabit Media Independent Interface)/XGMII (10 Gigabit Media Independent Interface);
Each MAC usually only requires one PHY, but PHY devices for high-speed network ports above 1000Mbps may need to convert the TBI interface to the SGMII interface or the XGMII interface to the XAUI interface through an internal PHY before connecting to the external PHY, thereby reducing the wiring difficulty of the external PHY;
TBI, XAUI, and interfaces such as MII, RGMII, SGMII, XGMII, GMII, QGMII are all part of the broadly defined MII interface, corresponding to the MII bus;
PHY must be connected to the MII bus and accessed through the MII controller;
The MII interface has two standards: MDIO22 and MIDO45, defined in 802.3ap clause 22 and Clause 45. The former supports 5-bit PHY addresses and 5-bit register addresses, while the latter adds 5-bit device addresses, allowing control of different sublayers of PHY; therefore, each MII controller can support up to 32 PHY devices through the MII bus;
Broadly defined network ports refer to the combination of MAC, MII controllers, and PHY.

0.2 Conventions

socket is the network interface proposed by the BSD protocol stack, which includes a receive buffer for sending and receiving data and controlling data transmission;
MBLK/Cluster/data is the buffer model proposed by the BSD protocol stack, where each data areadata corresponds to a Cluster, and each Cluster is associated with one MBLK. MBLK represents Ethernet frames and can chain multiple Ethernet frames together to improve data sending and receiving efficiency;
Taking the MPC5200 FEC network port on VxWorks 6.6 as an example, applicable to VxWorks 6.6 and earlier versions, and can serve as a reference for other version protocol stacks;
Non-critical function parameters and non-critical processes in the flowchart are omitted to highlight key points and reduce workload;

1. END Driver Architecture

The overall architecture of the END driver is shown below:

Where:

1. Users can access the protocol stack interface through three types of interfaces:

socket: Provided by the sockLib library, includingsocket/bind/connect/listen/accept/getsockopt/setsockopt/recv/recvfrom/recvmsg/send/sendmsg/sendto(); among them:
General IO interface: Provided by the sockLib library, includingclose/ioctl/write/ioctl();
ipcom/ipnet interface: Provided by ipcom/ipnet, includingifconfig;

2. sockLib library is located atvxworks-6.6/target/src/wrn/coreip/sysdep/os/vxWorks/socket, providing socket interface, and calls theiosDrvInstall() interface to install IO device drivers, thereby creating descriptors for each socket to provide general IO interface, among them:

socket/accept interface not only calls the ipcom/ipnet registeredsocketRtn/acceptRtn() hook function, but also needs to call the iosLib library interface to create IO devices as socket descriptors;
Other socket interfaces directly call the corresponding hook functions registered by ipcom/ipnet after simple parameter checks;
General IO interface corresponds to the sockLib library registeredsocketClose/socketRead/socketWrite/socketIoctl() interfaces when installing IO device drivers, these interfaces directly call the corresponding hook functions registered by ipcom/ipnet after simple parameter checks;

3. ipnet/ipcom is located atcomponents/ip_net2-6.6, using sockLibAdd() to register the protocol stack such as AF_NET/AF_PACKET and the function list containingsocket/bind/connect/listen/accept/getsockopt/setsockopt/recv/recvfrom/recvmsg/send/sendmsg/sendto() to the sockLib’s sockLibMap[];

ipcom provides OS encapsulation layer to mask differences between OSs and bind to the MUX layer, with the main code located atcomponents/ip_net2-6.6、ipcom/port/vxworks;
ipnet/ipcom callsmuxLib providedmuxDevStart/muxDevStop/muxIoctl/muxSend/muxDevLoad/muxDevUnload/muxBind/muxUnbind() interfaces to complete protocol stack binding, driver loading, network interface control, and data sending and receiving functions;

4. muxLib is located atvxworks-6.6/target/src/wrn/coreip/common/mux, used to bind the protocol stack to different network interfaces and provide network card control interfaces, including:

muxDevStart/muxDevStop/muxIoctl interfaces: mainly complete by calling the correspondingendLib encapsulated network card driver function list corresponding tostart/stop/ioctl hooks;
muxSend interface: First generates the address through theendLib encapsulated network card driver function list’sformAddress hook, then calls theendLib encapsulated network card driver function list’spacketDataGet hook and themuxBind installedstackRcvRtn to filter local packets, and finally calls theendLib encapsulated network card driver function list’ssend/formAddress/packetDataGet hooks to complete the sending function;
muxReceive interface: Uploads data to ipnet/ipcom through themuxBind installedstackRcvRtn;
muxDevLoad interface: Calls the driver providedxxxEndLoad interface to load the network card driver, then callsendLib providedendFlagsSet to set the END_MIB_2233 flag (m5200FecEnd does not support 2233 MIB), and uses ioctl to determine the end type to setpEnd->receiveRtn tomuxReceive (m5200FecEnd type is END_STYLE_END);

5. end layer is used to provide the encapsulated structure and common code for the network card driver.

2. Full Workflow of the Network Card Driver

2.1 Initialization Process

The entry point for network card driver initialization is usrNetworkInit():

usrNetworkInit: This is located in<project directory>/prjConfig.c, callsusrNetEndLibInit(), used to initialize the network card driver;
usrNetEndLibInit: This interface is located invxworks-6.6/target/src/config/usrNetwork.c or vxworks-6.6/target/config/comps/src/net/coreip/usrNetEndLib.c, the key process is as follows:

Where:

vxbDevMethodRun() traverses the VxBus drivers, calling all network card drivers that provide themuxDevConnect() interface, not applicable to the lite5200b Legacy network card driver;
endDevTbl[] array contains Legacy network card drivers, defined in the configNet.h in the BSP directory:

#define FEC_LOAD_FUNC m5200FecEndLoad
...
#define FEC_LOAD_STR "-1:0x0:-1:-1:0x40:0x30:0x0:0xff:2:0x4:" \
        FEC_CLOCK_SPEED(IPB_CLOCK_LITERAL)

#define FEC_BUFF_LOAN 1
...
END_TBL_ENTRY endDevTbl [] =
{
#ifdef INCLUDE_FEC_END
    { 0, FEC_LOAD_FUNC, FEC_LOAD_STR, FEC_BUFF_LOAN, NULL, FALSE},
#endif /* INCLUDE_FEC_END */
...
};

endPollStatsInit() is used to initialize the statistics of the network card driver.

3. muxDevLoad(): Located invxworks-6.6/target/src/wrn/coreip/common/mux/muxLib.c, used to call the initialization function of the Legacy network card driver in the endDevTbl[] arrayendLoad, the key process is as follows:

Where:

When calling endLoad for the first time, the parameter is an empty string, used to get the network port name, for example, ‘fec’;
When calling endLoad for the second time, the parameter is a combination of the network port unit number and the initialization string, used to formally load the network port;

4. muxDevStart(): Located invxworks-6.6/target/src/wrn/coreip/common/mux/muxLib.c, used to call the pEnd->pFuncTable->start() interface registered by the driver to start the network port and set the network port toIFF_UP | IFF_RUNNING state;

5. m5200FecEndLoad(): Driver interface, the main function is to register toendLib:

Allocate driver information structure and PHY information structure;
Callm5200FecInitParse to parse the initialization string and store it in the driver information structure;
Callm5200FecInitMem to apply for temporary sending buffer and create a netpool network buffer pool;
Callm5200FecSdmaTaskInit to create the Bestcomm SDMA task;
CallEND_OBJ_INIT i.e.endObjInit to initialize the END structure and register the network card driver function list;
CallEND_FLAGS_SET to set multicast and broadcast flags;

6. m5200FecStart(): Driver interface, the main function is to start the network port:

Callm5200FecReset to reset the Ethernet controller;
Callm5200FecTbdInit/m5200FecRbdInit to initialize the receive and transmit buffer descriptor rings;
CallSYS_FEC_INT_CONNECT i.e.intConnect to connect the BestComm send and receive task interrupts and the general interrupt handling function;
CallSYS_FEC_INT_ENABLE i.e.intEnable to enable interrupts;
Callm5200FecPrePhyConfig to initialize MAC address, set interrupt event mask, clear interrupt events, configure internal MII controller interface, etc.;
Callm5200FecPhyPreInit to set the PHY information structure working mode flag according to the flags in the driver information structure;
Call_func_m5200FecPhyInit i.e.m5200FecPhyInit to initialize PHY, and select auto-negotiation mode or forced mode according to the working mode flag in the PHY information structure;
CallTaskIntClear to clear the BestComm receive task interrupt;
CallTaskStart to start the BestComm receive task;
CallFEC_END_ETH_ENABLE to enable the Ethernet controller;
CallEND_FLAGS_SET to mark the network port asIFF_UP | IFF_RUNNING, i.e. working state;
CallnetJobAdd to addmuxTxRestart to the netJobQueueId queue maintained by the tNet0 task, and subsequently call thestackTxRestartRtn interface bound to the protocol stack on the network port to reset the protocol stack.

2.2 Sending Process

The entry point for the sending process is provided by the socket library’s send/sendto/sendmsg() and the write() provided by the ios subsystem:

send/sendto/sendmsg(): Calls the protocol stack using the SOCK_FUNC pointer registered by sockLibAdd() in the sendRtn/sendtoRtn/sendmsgRtn(), i.e.ipcom_windnet_send/sendto/sendmsg() located invxworks-6.6/target/src/wrn/coreip/sysdep/os/vxWorks/socket/sockLib.c;
write(): Calls the socketWrite() hook of the socket driver installed in the ios subsystem, and subsequently calls the socketWrite() registered by the SOCK_FUNC pointer in the protocol stack using sockLibAdd() in the socket library, i.e.ipcom_windnet_socketwrite(), located invxworks-6.6/target/src/wrn/coreip/sysdep/os/vxWorks/socket/sockLib.c;
ipcom_windnet_send/sendto/sendmsg/socketwrite(): Calls ipcom_send/sendto/sendmsg/send(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_sock.c;
ipcom_send/sendto/sendmsg/send(): Calls ipcom_sendmsg(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_sock.c;
ipcom_sendmsg(): Calls sock->ops->send(), i.e. the ipnet_init() registered and used by the socket() interface using ipcom_socket() to install the iptcp_send and ipnet_sock_udp_send interfaces;
iptcp_send and ipnet_sock_udp_send():

UDP branch:

ipnet_sock_udp_send(): Calls ops->i.network_send(), i.e. ipnet_ip4_sendto(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_udp.c;

TCP branch:

iptcp_send(): Calls iptcp_create_output_seg(), located incomponents/ip_net2-6.6/ipnet2/src/iptcp.c;
iptcp_create_output_seg(): Calls iptcp_output(), located incomponents/ip_net2-6.6/ipnet2/src/iptcp.c;
iptcp_output(): Calls iptcp_sendto(), located incomponents/ip_net2-6.6/ipnet2/src/iptcp.c;
iptcp_sendto(): Calls sock->ops->network_send(), i.e. ipnet_ip4_sendto(), located incomponents/ip_net2-6.6/ipnet2/src/iptcp.c;

7. ipnet_eth_ip4_output(): Calls ipnet_if_output(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_eth.c;

8. ipnet_if_output(): Calls ipnet_if_drv_output(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_netif.c;

9. ipnet_if_drv_output(): Calls netif->ipcom.drv_output(), i.e. ipcom_drv_eth_init installed ipcom_drv_eth_output(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_netif.c;

10. ipcom_drv_eth_output(): Calls muxSend(), located incomponents/ip_net2-6.6/ipcom/port/vxworks/src/ipcom_drv_eth.c;

11. muxSend(): Located incomponents/ip_net2-6.6/ipcom/port/vxworks/src/ipcom_drv_eth.c, usespEnd->pFuncTable->send() as a parameter to call_muxTkSendEnd for general processing, if parameter checks fail, directly releasespMBlk sending buffer;

12. _muxTkSendEnd: Located incomponents/ip_net2-6.6/ipcom/port/vxworks/src/ipcom_drv_eth.c, performs general processing:

Updates sending statistics in 2233 MIB;
If the destination MAC address is not empty, callspEnd->pFuncTable->formAddress i.e.m5200FecEndLoad installedendEtherAddressForm to construct the Ethernet header and put it in thepMBlk sending buffer;
If the network port has bound the protocol stack, callspEnd->pFuncTable->packetDataGet i.e.endEtherPacketDataGet to obtain the data pointer of thepMBlk sending buffer, and then callsmuxEndRcvRtn to receive data to the protocol stack;
CallsmuxSend to pass the hook callpEnd->pFuncTable->send(), i.e.m5200FecEndLoad function installedm5200FecSend();
If sending is blocked, i.e., the network port is busy, removes the Ethernet header from thepMBlk sending buffer, returns error information and waits for the protocol stack to send again;

13. m5200FecSend(): Driver interface that writes data into the sending buffer and sends it,

Checks parameters and working mode, fails and returns;
CalculatespMBlk sending buffer’s fragment count;
If the number of sending buffer descriptors is 0, callsm5200FecTbdClean to clean the sending buffer;
If the number of sending buffer descriptors is greater thanpMBlk sending buffer’s fragment count, and the buffer address meets alignment requirements, andm5200FecForceCopy is false, callsm5200FecPktTransmit; otherwise, callsm5200FecPktCopyTransmit;

14. m5200FecPktTransmit(): Driver interface that performs zero-copy transmission usingpMBlk sending buffer:

Callsm5200FecTbdListSet to obtain the sending buffer descriptor list;
Sets the sending buffer descriptor’s buffer pointer using the data pointers corresponding to each fragment of thepMBlk sending buffer and updates the sending buffer descriptor flags;
CallsTaskStart to start the BestComm sending task;
CallsCACHE_PIPE_FLUSH to flush the write buffer;

15. m5200FecPktCopyTransmit(): Driver interface that applies for a newMBLK from the driver-created netpool to save all data in thepMBlk sending buffer, and then sends it:

CallsNET_BUF_ALLOC to apply for a cluster, i.e., data buffer, if the application fails, uses the temporary sending buffer, and still fails returns sending blocked;
Aligns the sending buffer data address to 32 bytes;
Callsm5200FecTbdListSet to obtain the sending buffer descriptor list;
Uses the data pointers corresponding to each fragment of thepMBlk sending buffer to copy to the newly allocated sending buffer;
Sets the sending buffer descriptor’s buffer pointer using the new sending buffer’s pointer and updates the sending buffer descriptor flags;
CallsTaskStart to start the BestComm sending task;
CallsCACHE_PIPE_FLUSH to flush the write buffer;

16. m5200FecWdmaInt(): Driver interface that is triggered after the BestComm sending task is completed and calls this function:

CallsSDMA_INT_DISABLE to close the BestComm sending task interrupt;
CallsTaskIntClear to clear the BestComm sending task interrupt;
CallsCACHE_PIPE_FLUSH to flush the write buffer;
CallsnetJobAdd to addm5200FecTxHandle to the netJobQueueId queue maintained by the tNet0 task, if it fails, callsSDMA_INT_ENABLE to enable the BestComm sending task to exit;

17. m5200FecTxHandle(): Cleans up the sending buffer descriptors and the BestComm sending task:

Callsm5200FecTbdClean to clean the sending buffer;
CallsintLock to lock interrupts;
If the BestComm sending task status is non-empty, clears the current BestComm sending task status, callsintUnlock to unlock interrupts, then returns to callm5200FecTbdClean to clean the sending buffer, until the BestComm sending task status is empty and then callsintUnlock to unlock interrupts and exit.

2.3 Receiving Process

The user program entry for the receiving process is provided by the socket library’s recv/recvfrom/recvmsg() and the read() provided by the ios subsystem:

recv/recvfrom/recvmsg(): Calls the protocol stack using the SOCK_FUNC pointer registered by sockLibAdd() in the recvRtn/recvfromRtn/recvmsgRtn(), i.e.ipcom_windnet_recv/recvfrom/recvmsg() located invxworks-6.6/target/src/wrn/coreip/sysdep/os/vxWorks/socket/sockLib.c;
read(): Calls the socketRead() hook of the socket driver installed in the ios subsystem, and subsequently calls the socketRead() registered by the SOCK_FUNC pointer in the protocol stack using sockLibAdd() in the socket library, i.e.ipcom_windnet_socketread(), located invxworks-6.6/target/src/wrn/coreip/sysdep/os/vxWorks/socket/sockLib.c;
ipcom_windnet_recv/socketread(): Calls ipcom_recv(), then callsipcom_recvfrom, located incomponents/ip_net2-6.6/ipnet2/src/ipnet_sock.c;
ipcom_windnet_recvfrom/recvmsg(): Calls ipcom_recvfrom/recvmsg(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_sock.c;
ipcom_recvfrom(): Calls ipcom_recvmsg(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_sock.c;
ipcom_recvmsg(): Calls sock->ops->recv(), i.e., the ipnet_init() registered and used by the socket() interface using ipcom_socket() to install the iptcp_recv and ipnet_sock_pkt_recv interfaces;
iptcp_recv/ipnet_sock_pkt_recv(): If there are no messages in the socket’s receive buffer, it determines whether to directly return or suspend the task waiting for messages to arrive; otherwise, it retrieves the message, processes it, and returns it to the user program entry.

The driver program entry for the receiving process is the driver’s m5200FecRdmaInt:

m5200FecRdmaInt(): Callsm5200FecRxHandle to receive data:

Reads the receive FIFO status and prints debugging information;
CallsintLock to lock interrupts;
CallsSDMA_INT_DISABLE to close the receive DMA task interrupt;
CallsTaskIntClear to clear the BestComm receive task interrupt;
CallsintUnlock to unlock interrupts;
CallsCACHE_PIPE_FLUSH to flush the write buffer;
CallsnetJobAdd to addm5200FecRxHandle to the netJobQueueId queue maintained by the tNet0 task and exit;

2. m5200FecRxHandle(): Handles the BestComm receive task interrupt,

Callsm5200FecHandleRecvInt to receive data;
CallsintLock to lock interrupts;
If there are still BestComm receive task interrupts to be processed, callsTaskIntClear to clear the BestComm receive task interrupt, callsintUnlock to unlock interrupts, callsnetJobAdd to addm5200FecRxHandle to the netJobQueueId queue maintained by the tNet0 task, callsintLock to lock interrupts, and returns to the first step to callm5200FecHandleRecvInt to receive data, until there are no BestComm receive task interrupts to process, then callsSDMA_INT_ENABLE to enable the BestComm receive task interrupt and exit;

3. m5200FecHandleRecvInt(): Traverses the receive buffer descriptor ring queue, callsm5200FecReceive to receive data and upload it to the protocol stack;

4. m5200FecReceive(): Receives data and uploads it to the protocol stack,

If there are errors in the receive buffer descriptor, callsm5200FecRbdClean to clean the receive buffer descriptor and exit;
Applies for MBLK and cluster from the driver’s netpool buffer pool and associates them with the buffer pointer of the receive buffer descriptor, while applying for a new buffer from the driver’s netpool buffer pool to update the buffer pointer of the receive buffer descriptor;
Callsm5200FecRbdClean to clean the receive buffer descriptor;
CallsEND_RCV_RTN_CALL to upload data to the protocol stack.

5. END_RCV_RTN_CALL: CallspEnd->receiveRtn i.e.muxReceive, if it fails, callsnetMblkClChainFree to release the sending bufferpMBLK;

6. muxReceive(): Receives data and uploads it to the protocol stack:

CallspEnd->pFuncTable->packetDataGet i.e.endEtherPacketDataGet to obtain the data pointer of thepMBlk receive buffer;
Gets the message type from the Ethernet header;
Traverses the protocol stack bound to the network port, if matched, calls the receiving function of the protocol stackpProto->rr.endRcv i.e.muxEndRcvRtn to place data into the protocol stack’s buffer;
Updates the receiving statistics in the 2233 MIB;
CallsnetMblkClChainFree to release the sending bufferpMBLK;

7. muxEndRcvRtn(): CallspBinding->stackRcvRtn i.e. the protocol stack callsmuxBind boundstackRcvRtn function pointer to upload data to the protocol stack’s buffer.

3. ifconfig up/down Process

The entry point of ifconfig is located invxworks-6.6/target/src/wrn/coreip/wrapper/utilslib/ifconfig.c, the main process is as follows:

ifconfig(): Calls ipnet_cmd_ifconfig(), located invxworks-6.6/target/src/wrn/coreip/wrapper/utilslib/ifconfig.c;
ipnet_cmd_ifconfig(): Calls ipcom_socket() to create a socket, and then uses IP_TRUE and IP_FALSE to call ipnet_ifconfig_if_change_state(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_cmd_ifconfig.c;
ipnet_ifconfig_if_change_state(): Uses IP_SIOCSIFFLAGS and sets or clears IP_IFF_UP to call ipcom_socketioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_ioctl.c;
ipcom_socketioctl(): Calls ipnet_do_ioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_ioctl.c;
ipnet_do_ioctl(): Calls ipnet_ioctl_if(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_ioctl.c;
ipnet_ioctl_if(): Uses IP_SIOCXOPEN or IP_SIOCXCLOSE to call ipnet_if_link_ioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_netif.c;
ipnet_if_link_ioctl(): Calls netif->link_ioctl(), i.e., through ipnet_eth_if_init() installed ipnet_eth_ioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_netif.c;
ipnet_eth_ioctl(): Calls ipnet_if_drv_ioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_eth.c;
ipnet_if_drv_ioctl(): Calls ipnet_if_clean_snd_queue() to clean and reset the queue on the current interface, then calls netif->ipcom.drv_ioctl(), i.e., through ipcom_drv_eth_init() installed ipcom_drv_eth_ioctl(), located incomponents/ip_net2-6.6/ipnet2/src/ipnet_netif.c;
ipcom_drv_eth_ioctl(): For IP_SIOCXOPEN calls ipnet_drv_eth_sync_with_end_flags(), for IP_SIOCXCLOSE calls netif->link_ioevent i.e. ipnet_eth_ioevent() to notify the protocol stack that the network port is in IP_EIOXSTOP, located incomponents/ip_net2-6.6/ipnet2/src/ipnet_eth.c;
ipnet_drv_eth_sync_with_end_flags(): Calls muxIoctl to obtain network port flags and states, if the network port is active, calls netif->link_ioevent i.e. ipnet_eth_ioevent() to notify the protocol stack that the network port is in IP_EIOXRUNNING state.

In summary, ifconfig up/down does not actually operate the network card driver, it only cleans and resets the current queue on the network port, and then notifies the protocol stack that the network port is in IP_EIOXRUNNING or IP_EIOXSTOP state.

0. Overview

0.1 Network Interface

0.2 Conventions

1. END Driver Architecture

2. Full Workflow of the Network Card Driver

2.1 Initialization Process

2.2 Sending Process

2.3 Receiving Process

3. ifconfig up/down Process

Related posts:

Leave a Comment Cancel reply