Re: [ECOS] Ethernet Drivers Questions

[Jonathan Larmour <jlarmour at redhat dot com>]

David Webster wrote:
> 
> 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.

The driver_doc does seem to be lagging the implementation I'm afraid. I've
just added this:

HRDWR_deliver(struct eth_drv_sc *sc)
=========================================================================

This function is actually a call back, and notifies the driver that
delivery
is happening. This allows it to actually do the copy of packet data to/from
the hardware from/to the packet buffer. And once that's done, then do
things
like unmask its interrupts, and free any relevant resources so it can
process
further packets.

In general it will be called from the user thread responsible for
delivering
network packets.

static void
HRDWR_poll(struct eth_drv_sc *sc)
=========================================================================

This function is used when in a non-interrupt driven system, e.g. when
interrupts are completely disabled. This allows the driver time to check
whether anything needs doing either for transmission, or to check if
anything has been received, or if any other processing needs doing..

static int
HRDWR_int_vector(struct eth_drv_sc *sc)
=========================================================================

This function returns the interrupt vector number used for RX interrupts.
This is so the common GDB stubs infrastructure can detect when to check
for incoming ctrl-c's when doing debugging over ethernet.


>         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?

Yes it's still okay, it just degrades real-time performance due to copying
large amounts of data with the scheduler locked. No devices in the current
repository work like that any more. The ones in 1.3.1 probably did.
 
> 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).

I believe so. And in the future, we would need to support hardware that can
do its own scatter/gather anyway.
 
Don't know about your question 3 (and no time to look, as ever), sorry.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine