|MC_TX(9E)||Driver Entry Points||MC_TX(9E)|
mc_tx() entry point is called when the system requires a device driver to transmit data. The device driver will receive a chain of message blocks. The mp_chain argument represents the first frame. The frame may be spread out across one or more mblk(9S) structures that are linked together by the b_cont member. There may be multiple frames, linked together by the b_next pointer of the mblk(9S).
For each frame, the driver should allocate the required resources and prepare it for being transmitted on the wire. The driver may opt to copy those resources to a DMA buffer or it may bind them. For more information on these options, see the MBLKS AND DMA section of mac(9E).
As it processes each frame in the chain, if the device driver has advertised either of the MAC_CAPAB_HCKSUM or MAC_CAPAB_LSO flags, it must check whether either apply for the given frame using the mac_hcksum_get(9F) and mac_lso_get(9F) functions respectively. If either is enabled for the given frame, the hardware must arrange for that to be taken care of.
For each frame that the device driver processes it is responsible for doing one of three things with it:
The device driver is in charge of the memory associated with mp_chain. If the device driver does not return the message blocks to the GLDv3, then it must call freemsg(9F) on the frames. If it does not, the memory associated with them will be leaked. When a frame is being transmitted, if the device driver performed DMA binding, it should not free the message block until after it is guaranteed that the frame has been transmitted. If the message block was copied to a DMA buffer, then it is allowed to call freemsg(9F) at any point.
In general, the device driver should not drop frames without transmitting them unless it has no other choice. Times when this happens may include the device driver being in a state where it can't transmit, an error was found in the frame while trying to establish the checksum or LSO state, or some other kind of error that represents an issue with the passed frame.
The device driver should not free the chain when it does not have enough resources. For example, if entries in a device's descriptor ring fill up, then it should not drop those frames and instead should return all of the frames that were not transmitted. This indicates to the stack that the device is full and that flow control should be asserted. Back pressure will be applied to the rest of the stack, allowing most systems to behave better.
Once a device driver has returned unprocessed frames from its
mc_tx() entry point, then the device driver will not
receive any additional calls to its
point until it calls
mac_tx_update(9F) to indicate
that resources are available again. Note that because it is the device
driver that is calling this function to indicate resources are available, it
is very important that it only return frames in cases where the device
driver itself will be notified that resources are available again. For
example, when it receives an interrupt indicating that the data that it
transmitted has been completed so it can use entries in its descriptor ring
or other data structures again.
The device driver can obtain access to its soft state through the driver member. It should cast it to the appropriate structure. The device driver should employ any necessary locking to access the transmit related data structures. Note that the device driver should expect that it may have its transmit endpoints called into from other threads while it's servicing device interrupts related to them.
mc_tx() entry point may be called from kernel or interrupt context.
NULL. Otherwise, it should return all unprocessed message blocks and ensure that it calls mac_tx_update(9F) some time in the future.
|November 26, 2017||OmniOS|