This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Ethernet Drivers Questions


Hi,

	I'm looking at writing an Ethernet driver for our proprietary
hardware and had a couple of questions:

1.	I notice from the existing drivers that the eth_hwr_funs
structure (and ETH_DRV_SC macro) have been modified from the driver_doc
readme file to include 3 additional fields (deliver, poll and
int_vector). Is there an updated driver_doc to reflect these? If not can
somebody clarify my understanding of what this is doing.
	"Normally" an ISR does as little as possible and returns
CYG_ISR_CALL_DSR which causes the isr's DSR to be called. For Ethernet
drivers the DSR must be set to eth_drv_dsr. When this is called it
causes the TCP/IP stacks' alarm thread to be woken up - which in turn
polls every Ethernet driver to see if the deliver function needs to be
called which means that the "expensive" operation of servicing the
Ethernet interrupt is done at user task level - not interrupt level.
This sounds great and I'll use this mechanism for one of my Ethernet
interfaces.
	However the other interface I've got really needs to be serviced
asap and as such I'd like to use the "old style" ISR/DSR approach. I
can't see any reason why there should be a problem doing this but I'd
like some confirmation that this is still ok? Do any other Ethernet
interfaces work like this?

2.	On the transmit side I notice that currently all the existing
drivers perform a memcpy from the sg_list into some local memory from
which the Ethernet chip transmits. Then when the frame has been sent the
driver calls tx_done to indicate that the frame has gone. My hardware
could directly access the sg_list scatter gather list so I could remove
the memcpy - can the TCP/IP stack handle this? I assume it can because
(I'm guessing here!) that it doesn't re-use the buffer until it gets a
tx_done. It looks ok to me but there's a note in the driver_doc readme
that worries me and that I don't really understand - it says:
		"FUTURE: This function may be extended so that the data
need not be
copied by having the function return a "disposition" code (done, send
pending, etc).  At this point, you should move the data to some "safe"
location before returning."
	Does anybody know whether I can safely remove the memcpy? Also
what about the redboot stack can it manage without the mempy (this is
obviously less of an issue as it's only boot code).

3.	A similar question to 2, but on the receive side, is there
anyway to remove the memcpy from the local buffer used by the Ethernet
chip to the sg_list used by the net stack? Has anybody tried anything
like this? Could my low level driver allocate mbufs for the Ethernet
chip to use and then swap over the pointers passed in the sg_list to the
recv function.  My understanding is that the fist sg_list entry is an
auto variable used to hold the MAC header and the remainder is a mbuf
cluster big enough for the entire rx frame? Can anybody point me to a
description/documentation on mbufs?
	This looks much more complex than the rx side - so maybe I'll
get a memcpy driver working first and then look into what's involved
trying to remove the memcpy.


	Thanks
		Dave Webster






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]