Krishna Kumar wrote:
> @@ -3397,6 +3440,28 @@ int register_netdevice(struct net_device
>               }
>       }
>  
> +     if (dev->features & NETIF_F_BATCH_SKBS) {
> +             if (!dev->hard_start_xmit_batch ||
> +                 dev->tx_queue_len < MIN_QUEUE_LEN_BATCH) {
> +                     /*
> +                      * Batch TX requires API support in driver plus have
> +                      * a minimum sized queue.
> +                      */
> +                     printk(KERN_ERR "%s: Dropping NETIF_F_BATCH_SKBS "
> +                                     "since no API support or queue len "
> +                                     "is smaller than %d.\n",
> +                                     dev->name, MIN_QUEUE_LEN_BATCH);
> +                     dev->features &= ~NETIF_F_BATCH_SKBS;


The queue length can be changed through multiple interfaces, if that
really is important you need to catch these cases too.

> +             } else {
> +                     dev->skb_blist = kmalloc(sizeof *dev->skb_blist,
> +                                              GFP_KERNEL);


Why not simply put the head in struct net_device? It seems to me that
this could also be used for gso_skb.

> +                     if (dev->skb_blist) {
> +                             skb_queue_head_init(dev->skb_blist);
> +                             dev->tx_queue_len >>= 1;
> +                     }
> +             }
> +     }
> +
>       /*
>        *      nil rebuild_header routine,
>        *      that should be never called and used as just bug trap.
> @@ -3732,10 +3797,16 @@ void unregister_netdevice(struct net_dev
>  
>       synchronize_net();
>  
> +     /* Deallocate batching structure */
> +     if (dev->skb_blist) {
> +             skb_queue_purge(dev->skb_blist);
> +             kfree(dev->skb_blist);
> +             dev->skb_blist = NULL;
> +     }
> +

Queue purging should be done in dev_deactivate.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to