Return to enet.Questions CVS log

Up to [Apple Darwin 0.x] / driverkit / notes

Annotation of driverkit/notes/enet.Questions, revision 1.1.1.1

1.1       root        1:                        Ethernet questions
                      2:                        
                      3: 1. Why does the 68k driver use IF_ENQUEUE and IF_DEQUEUE? These look like 
                      4:    private macros for the netif module...They'll prevent us from using 
                      5:    only netif.h! How to enqueue and dequeue from netif_t legally?
                      6:    
                      7:    -- Maybe don't have to enqueue mbufs on netif; 68k had to do that 
                      8:       because of finite-size DMA queue...We should just be able to 
                      9:       chan_dma_enqueue 'em.
                     10: 
                     11: 2. How important is it to use netbuf's instead of mbufs? Is this actually 
                     12:    possible in current system (without a lot of hacking outside of enet
                     13:    driver)?
                     14:    
                     15:    -- Brad says: go for it, by the book. OK, let's try it.
                     16:    
                     17: 3. Re: this comment at top of enoutput():
                     18: 
                     19:    Use trailer local net encapsulation if enough data in first
                     20:    packet leaves a multiple of 512 bytes of data in remainder.
                     21: 
                     22:    I don't see any code which does this.
                     23:    
                     24:    -- I think that the enet driver doesn't have to worry about this; 
                     25:       it's handled in if_venip.c.
                     26:    
                     27: 4. engetbuf, I assume, is never called from interrupt level, since 
                     28:    it calls nb_alloc_wrapper, which the tech docs say can not be called
                     29:    from interrupt level. However, 
                     30:    engetbuf() {
                     31:        en_get()
                     32:                enbuf_alloc()
                     33:                        m_clalloc() ...
                     34:                        
                     35:    m_clalloc() has a hack to allocate memory at interrupt level. 
                     36:    
                     37:    Will a network module's output or getbuf routines in fact be called
                     38:    at interrupt level?
                     39:    
                     40:    -- Brad and Joel G. both say NO. I'm going to go ahead and assume that
                     41:       I can do RPCs and kallocs from both routines. Brad agreed to help fix
                     42:       deadlock problems which may arise from this. 
                     43:                
                     44: 5. Maybe we want the enetBuf's to always be wired. If so, kern_dev needs 
                     45:    one of two changes:
                     46:      -- at dma_enqueue() time, rememeber if current vm_region is pageable;
                     47:         if not, don't bother wiring it, and don't unwire it at dequeue time 
                     48:      -- att arg to chan_dma_enqueue_int() to specifiy whether or not to bother
                     49:         wiring and unwiring the memory.
                     50:        

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.