This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

Re: Ethernet interrupt structure / flow


> > static void
> > vt8235_dsr(cyg_vector_t vector, cyg_ucount32 count, cyg_addrword_t data)
> > {
> >     struct vt8235_priv_data* cpd = (struct vt8235_priv_data *)data;
> >     struct cyg_netdevtab_entry *ndp = (struct cyg_netdevtab_entry 
> *)(cpd->ndp);
> >     struct eth_drv_sc *sc = (struct eth_drv_sc *)(ndp->device_instance);
> >
> >     // but here, it must be a *sc:
> >     eth_drv_dsr( vector, count, (cyg_addrword_t)sc );
> > }
> 
> This get's called as the DSR, which turns around and calls, eth_drv_dsr 
> which schedules a thread to get deliveries? Why the extra level of 
> indirection? Couldn't the deliver function run in the context of generic 
> "collector of deliveries" thread that is annotated by the call to the isr 
> routine?

Networking, by definition, is none real time. It can also take a long
time to actually service the interrupt, transfer the packets and
process it in the IP stack etc. You don't want to be doing this none
real time stuff inside the DSR since it will stop your real time
threads from running. Hence it is necassary to get a thread to do all
the work. The thread then has lower priority than your real time
processing and so won't upset it.

> And a double indirection again to deliver, to poll, then back to deliver 
> then back to the delivery thread. Any idea how much latency this is adding?

It is a design decission. Real time comes first, which results in some
none real time things suffering a little in terms of efficiency,
latency and performace. If you want really high performance
networking, you probably don't want to be using a RTOS.

> Final question for this email. I know that redboot only uses the poll 
> function for networking being an inherently simple monitor model. Is it 
> possible to allow it to use the interrupt version or is that simply not an 
> option at this time?

It is not an option.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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