Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-27 Thread Mahesh Bandewar
On Fri, Apr 24, 2015 at 3:59 PM, Dan Williams wrote: > On Fri, 2015-04-24 at 15:40 -0700, Mahesh Bandewar wrote: >> On Fri, Apr 24, 2015 at 1:15 PM, Dan Williams wrote: >> > On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: >> >> Processing multicast / broadcast in fast path is performanc

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-24 Thread Dan Williams
On Fri, 2015-04-24 at 15:40 -0700, Mahesh Bandewar wrote: > On Fri, Apr 24, 2015 at 1:15 PM, Dan Williams wrote: > > On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: > >> Processing multicast / broadcast in fast path is performance draining > >> and having more links means more clonning a

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-24 Thread Mahesh Bandewar
On Fri, Apr 24, 2015 at 1:15 PM, Dan Williams wrote: > On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: >> Processing multicast / broadcast in fast path is performance draining >> and having more links means more clonning and bringing performance >> down further. >> >> Broadcast; in parti

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-24 Thread Dan Williams
On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: > Processing multicast / broadcast in fast path is performance draining > and having more links means more clonning and bringing performance > down further. > > Broadcast; in particular, need to be given to all the virtual links. > Earlier

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread Mahesh Bandewar
On Thu, Apr 23, 2015 at 9:28 PM, David Miller wrote: > From: Mahesh Bandewar > Date: Thu, 23 Apr 2015 19:54:29 -0700 > >> On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote: >>> On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: >>> +static void ipvlan_multicast_enqueue(struct ipvl_

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread David Miller
From: Mahesh Bandewar Date: Thu, 23 Apr 2015 19:54:29 -0700 > On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote: >> On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: >> >>> +static void ipvlan_multicast_enqueue(struct ipvl_port *port, >>> + struct sk_bu

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread Eric Dumazet
On Thu, 2015-04-23 at 19:54 -0700, Mahesh Bandewar wrote: > The only possibility of schedule_work() while doing kfree_skb() is > when the queue limit is reached. How can the queue be reduced if not > scheduled? May be I'm missing something.. What is the point calling schedule_work() if you queue

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread Mahesh Bandewar
On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote: > On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: > >> +static void ipvlan_multicast_enqueue(struct ipvl_port *port, >> + struct sk_buff *skb) >> +{ >> + if (skb->protocol == htons(ETH_P_PAUSE)) >>

Re: [PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread Eric Dumazet
On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: > +static void ipvlan_multicast_enqueue(struct ipvl_port *port, > + struct sk_buff *skb) > +{ > + if (skb->protocol == htons(ETH_P_PAUSE)) > + return; But what happens to this packet ? It se

[PATCH next 1/3] ipvlan: Defer multicast / broadcast processing to a work-queue

2015-04-23 Thread Mahesh Bandewar
Processing multicast / broadcast in fast path is performance draining and having more links means more clonning and bringing performance down further. Broadcast; in particular, need to be given to all the virtual links. Earlier tricks of enabling broadcast bit for IPv4 only interfaces are not real