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     ! 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.