Francois Romieu <rom...@fr.zoreil.com> writes:
>> +static int nb8800_poll(struct napi_struct *napi, int budget)
>> +{
>> + struct net_device *dev = napi->dev;
>> + struct nb8800_priv *priv = netdev_priv(dev);
>> + struct nb8800_dma_desc *rx;
>> + int work = 0;
>> + int last = priv->rx_eoc;
>> + int next;
>> +
>> + while (work < budget) {
>> + struct rx_buf *rx_buf;
>> + u32 report;
>> + int len;
>> +
>> + next = (last + 1) & (RX_DESC_COUNT - 1);
>> +
>> + rx_buf = &priv->rx_bufs[next];
>> + rx = &priv->rx_descs[next];
>> + report = rx->report;
>> +
>> + if (!report)
>> + break;
>> +
>> + if (IS_RX_ERROR(report)) {
>> + nb8800_rx_error(dev, report);
>> + } else if (likely(rx_buf->page)) {
>> + len = RX_BYTES_TRANSFERRED(report);
>> + nb8800_receive(dev, next, len);
>> + }
>> +
>> + rx->report = 0;
>> + if (!rx_buf->page)
>> + nb8800_alloc_rx(dev, next, true);
>
> It looks like it receives, then tries to allocate new resources. If so
> it may deplete the ring and you should instead consider allocating new
> resources first, then receive data if alloc + map suceeded.
The hardware receives a frame and stores it in the provided DMA buffer,
then raises an interrupt and moves on to the next buffer. When a buffer
is handed over to the network stack, a new one has to take its place in
the DMA queue. I'm not sure how you're suggesting this be done
differently.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
