[ovs-dev] [patch v2 1/7] datapath: dont use non-existent receive hooks

Simon Horman horms at verge.net.au
Mon Aug 23 03:46:07 UTC 2010


On Fri, Aug 20, 2010 at 03:42:47PM -0400, Jesse Gross wrote:
> On Wed, Aug 18, 2010 at 11:36 PM, Simon Horman <horms at verge.net.au> wrote:
> > -static void netdev_port_receive(struct net_bridge_port *, struct sk_buff *);
> > +static void netdev_port_receive(struct vport *vport, struct sk_buff *skb);
> >
> >  /*
> >  * Used as br_handle_frame_hook.  (Cannot run bridge at the same time, even on
> >  * different set of devices!)
> >  */
> 
> Maybe move this comment down somewhat or otherwise clarify that it
> only applies to kernels < 2.6.36?

I have move the commend down and duplicated it to refer to
the two versions of the older-kernel hook.

> > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22)
> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
> > +/* Called with rcu_read_lock and bottom-halves disabled. */
> > +static struct sk_buff *netdev_frame_hook(struct sk_buff *skb)
> > +{
> > +       struct vport *vport;
> > +
> > +       if (skb->pkt_type == PACKET_LOOPBACK)
> > +               return skb;
> 
> Hopefully this won't be too common.  Maybe add an unlikely()?

I'd like to get a comment on that by suggesting the change
for the upstream bridge code (which is where I got this code from).

http://marc.info/?l=linux-netdev&m=128253454031924&w=2

> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
> > +static inline int netdev_rx_handler_register(struct net_device *dev,
> > +                                            rx_handler_func_t *rx_handler,
> > +                                            void *rx_handler_data)
> 
> On kernels less than 2.6.36 rx_handler_func_t will not be defined.  My
> first thought was to just use the typedef from the mainline source but
> that makes the compiler unhappy because netdev_frame_hook() on older
> kernels has a different prototype.  Since we never use it here I think
> it's easier to just make it a void *.

Agreed. I have made it void *.





More information about the dev mailing list