02.03.2014 Views

BSP Developer's Guide

BSP Developer's Guide

BSP Developer's Guide

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

VxWorks 5.5<br />

<strong>BSP</strong> Developer’s <strong>Guide</strong><br />

0x806 for ARP, and so on) and then searches its protocol list to see if any have<br />

registered using this protocol type.<br />

If there is a protocol that can handle this packet, the MUX passes the packet into<br />

the stackRcvRtn( ) specified in the protocol’s muxBind( ) call. Before passing the<br />

packet to a numbered protocol (that is, a protocol that is neither a<br />

MUX_PROTO_SNARF nor a MUX_PROTO_PROMISC protocol) muxReceive( ) calls<br />

the muxPacketDataGet( ) routine and passes two mBlks into the protocol.<br />

The first mBlk contains all the link-level information. The second mBlk contains<br />

all the information that comes just after the link-level header. This partitioning of<br />

the data lets the protocol skip over the header information (it also breaks the BSD<br />

4.3 model at the do_protocol_with_type( ) interface). The protocol then takes over<br />

processing the packet.<br />

This new method of multiplexing received packets does away with the method<br />

based on the etherInputHook( ) and etherOutputHook( ) routines. If a protocol<br />

wants to see all the undelivered packets received on an interface, it specifies its<br />

type as MUX_PROTO_PROMISC.<br />

If a protocol needs to modify data received from the network, it should copy that<br />

data first. Because other protocols might also want to see the raw data, the data<br />

should not be modified in place (that is, in the received buffer).<br />

Supporting Scatter/Gather Devices<br />

Some devices support breaking up a single network packet into separate chunks<br />

of memory. This makes it possible to pass a packet down (such as list of mbufs from<br />

a Berkeley-type TCP/IP protocol) as a chain of mBlk/clBlk/cluster constructs.<br />

Each mBlk in the chain is linked to the next mBlk using the<br />

mBlk.mBlkHdr.mNext member. The driver deals with the chain appropriately on<br />

transmission.<br />

Protocol Transmission Restart<br />

One of the features of the MUX/END API is to allow a device to tell a protocol<br />

when it has run out of resources. Protocols usually have a queue of packets that<br />

they are trying to transmit. If the device returns an END_ERR_BLOCK from a<br />

muxSend( ) call, the device is out of the resources necessary to send the data. The<br />

protocol should now stop transmitting. After the device knows that it has the<br />

resources necessary to transmit again, it can call the muxTxRestart( ) routine<br />

which in turn calls the stackTxRestartRtn( ) of each protocol attached to that<br />

304

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!