On Tue, Jan 04, 2005 at 04:06:07PM -0600, Jon Mason wrote: > On Tuesday 28 December 2004 06:10 pm, Marc Singer wrote: > > I'm implementing a new network driver. In reading other drivers and > > the documentation, I'm finding that there is a new (-er) interface > > that is recommended. > > > > The target is an embedded MAC of an ARM7 CPU with an integrated DMA > > controller. > > > > 1) Is there any reason not mentioned in the HOWTO for not > > implementing NAPI? > > NAPI is based on a timer. So there is a trade off between interrupt > servicing and slightly delayed packet servicing (plus the extra CPU > load for the timer). If you have a realtime system, then I would think > that NAPI isn't the best thing for it. It all depends on how much work there is to do, no? One interrupt per packet is going to hurt no matter what type of system it is...as long as the load is high. > > > 2) I've read that it is a bad idea to hang-on to SKBs. With DMA > > this CPU can eliminate the packet copying, but that means that > > the receive queue will have SKBs laying around. Is this > > acceptable? > > I don't know why it would be bad to hang on to SKBs. Most drivers keep > them around if they are less than their rx_copybreak def. There's a note, somewhere, about not doing so. It says something about a user-mode client being starved. It seems to me that the driver ought to be able to hang-on to SKBs. The thing is, my first version has 16 of them for the receive queue and up to 16 pending transmit. > > 3) In the prerequisites (from the HOWTO) > > > > B) Ability to turn off interrupts or maybe events that send > > packets up the stack. > > > > What does this sentence mean? > > Most/All adapters have the ability to disable interrupts (or conversely > to enable interrupts). This is need for NAPI to be used, the ability to > disable interrupts and have the NAPI timer handle all incoming (and > outgoing) packets. Ability to turn of interrupts makes sense. What is "maybe events..."? > > 4) I'm presently DMAing into an SKB. While there are other > > problems that challeng the driver, it looks like buffers are > > not being properly received by netif. > > > > Here's what I'm doing when a packet comes in: > > > > struct sk_buff* skb = emac->rg_rx_skb[emac->head_rx]; > > size_t packet_len = emac->rg_rx_descriptor[emac->head_rx *2+1] & 0x7ff; > > net_d->last_rx = jiffies; > > skb->protocol = eth_type_trans (skb, net_d); > > skb_put (skb, packet_len); > > PRINT_PKT (skb->data, packet_len > 64 ? 64 : packet_len); > > netif_rx (skb); > > I don't see any unmapping of the DMA address. I don't need to. The data is transferred directly to the SKB by the EMAC. The PHY address is set when the descriptor is initialized. Here's the rest of that fragment. netif_rx (skb); skb = ALLOC_SKB (PACKET_LENGTH_MAX); skb->dev = net_d; emac->rg_rx_skb[emac->head_rx] = skb; pa = virt_to_phys (skb->data); emac->rg_rx_descriptor[emac->head_rx*2] = (pa & ~3) | ((emac->head_rx == RX_QUEUE_LENGTH - 1) ? (1<<1) : 0); emac->rg_rx_descriptor[emac->head_rx*2 + 1] = PACKET_LENGTH_MAX; emac->head_rx = (emac->head_rx + 1)%RX_QUEUE_LENGTH; > > I've not found a good example. Is this right using the old interface? > > There are plenty of good examples out there. Look at any of the newer ethernet device drivers. How does one tell which are newer? Cheers. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
