Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

On Thu, Aug 31, 2017 at 6:58 AM, wrote: > [ resend due to mail problems at my end ] > > Hi Jesse, > > The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971, > "tunnels: Don't apply GRO to multiple layers of encapsulation", > to linux-4.1.y seems to have missed a

Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

On Thu, Aug 31, 2017 at 6:58 AM, wrote: > [ resend due to mail problems at my end ] > > Hi Jesse, > > The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971, > "tunnels: Don't apply GRO to multiple layers of encapsulation", > to linux-4.1.y seems to have missed a line. > > The 4.1 commit is

Re: [PATCH] geneve: fix max_mtu setting

On Mon, Jun 27, 2016 at 6:27 PM, 严海双 <yanhaishu...@cmss.chinamobile.com> wrote: > > On Jun 28, 2016, at 12:10 AM, Jesse Gross <je...@kernel.org> wrote: > > On Sun, Jun 26, 2016 at 6:13 PM, Haishuang Yan > <yanhaishu...@cmss.chinamobile.com> wrote: > > > O

Re: [PATCH] geneve: fix max_mtu setting

On Mon, Jun 27, 2016 at 6:27 PM, 严海双 wrote: > > On Jun 28, 2016, at 12:10 AM, Jesse Gross wrote: > > On Sun, Jun 26, 2016 at 6:13 PM, Haishuang Yan > wrote: > > > On Jun 26, 2016, at 8:35 PM, zhuyj wrote: > > + if (geneve->remote.sa.sa_family == A

Re: [PATCH] geneve: fix max_mtu setting

On Sun, Jun 26, 2016 at 6:13 PM, 严海双 wrote: > >> On Jun 26, 2016, at 8:35 PM, zhuyj wrote: >> >> + if (geneve->remote.sa.sa_family == AF_INET) >> + max_mtu -= sizeof(struct iphdr); >> + else >> +

Re: [PATCH] geneve: fix max_mtu setting

On Sun, Jun 26, 2016 at 6:13 PM, 严海双 wrote: > >> On Jun 26, 2016, at 8:35 PM, zhuyj wrote: >> >> + if (geneve->remote.sa.sa_family == AF_INET) >> + max_mtu -= sizeof(struct iphdr); >> + else >> + max_mtu -= sizeof(struct ipv6hdr); >> >> Sorry, if sa_family

Re: [ovs-dev] [PATCH] openvswitch: reduce padding in struct sw_flow_key

On Fri, Mar 18, 2016 at 6:34 AM, Arnd Bergmann wrote: > This means it's still too large really, we just don't warn about it any more, > and will get the warning again once another member is added. My patch is a > band-aid at best, but more work is needed here. One problem is that >

Re: [ovs-dev] [PATCH] openvswitch: reduce padding in struct sw_flow_key

On Fri, Mar 18, 2016 at 6:34 AM, Arnd Bergmann wrote: > This means it's still too large really, we just don't warn about it any more, > and will get the warning again once another member is added. My patch is a > band-aid at best, but more work is needed here. One problem is that >

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Fri, Oct 9, 2015 at 8:54 AM, Jarno Rajahalme wrote: > > On Oct 8, 2015, at 4:03 PM, Jesse Gross wrote: > > On Wed, Oct 7, 2015 at 10:47 AM, Jarno Rajahalme > wrote: > > > On Oct 6, 2015, at 6:01 PM, Jesse Gross wrote: > > On Mon, Oct 5, 2015 at 1:25 PM, Alexa

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Fri, Oct 9, 2015 at 8:54 AM, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > On Oct 8, 2015, at 4:03 PM, Jesse Gross <je...@nicira.com> wrote: > > On Wed, Oct 7, 2015 at 10:47 AM, Jarno Rajahalme <jrajaha...@nicira.com> > wrote: > > > On Oct 6, 2015,

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Wed, Oct 7, 2015 at 10:47 AM, Jarno Rajahalme wrote: > >> On Oct 6, 2015, at 6:01 PM, Jesse Gross wrote: >> >> On Mon, Oct 5, 2015 at 1:25 PM, Alexander Duyck >> wrote: >>> On 10/05/2015 06:59 AM, Vlastimil Babka wrote: >>>> >>

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Wed, Oct 7, 2015 at 10:47 AM, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > >> On Oct 6, 2015, at 6:01 PM, Jesse Gross <je...@nicira.com> wrote: >> >> On Mon, Oct 5, 2015 at 1:25 PM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Mon, Oct 5, 2015 at 1:25 PM, Alexander Duyck wrote: > On 10/05/2015 06:59 AM, Vlastimil Babka wrote: >> >> On 10/02/2015 12:18 PM, Konstantin Khlebnikov wrote: >>> >>> When openvswitch tries allocate memory from offline numa node 0: >>> stats = kmem_cache_alloc_node(flow_stats_cache,

Re: [ovs-dev] [PATCH] ovs: do not allocate memory from offline numa node

On Mon, Oct 5, 2015 at 1:25 PM, Alexander Duyck wrote: > On 10/05/2015 06:59 AM, Vlastimil Babka wrote: >> >> On 10/02/2015 12:18 PM, Konstantin Khlebnikov wrote: >>> >>> When openvswitch tries allocate memory from offline numa node 0: >>> stats =

Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()

On Tue, Aug 4, 2015 at 9:40 PM, Joe Stringer wrote: > On 1 August 2015 at 12:17, Thomas Graf wrote: >> On 07/31/15 at 10:51am, Joe Stringer wrote: >>> On 31 July 2015 at 07:34, Hannes Frederic Sowa wrote: >>> > In general, this shouldn't be necessary as the packet should already be >>> >

Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()

On Tue, Aug 4, 2015 at 9:40 PM, Joe Stringer joestrin...@nicira.com wrote: On 1 August 2015 at 12:17, Thomas Graf tg...@suug.ch wrote: On 07/31/15 at 10:51am, Joe Stringer wrote: On 31 July 2015 at 07:34, Hannes Frederic Sowa han...@redhat.com wrote: In general, this shouldn't be necessary as

Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()

On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross wrote: > On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher > wrote: >> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote: >>> ndo_gso_check() was recently introduced to allow NICs to report the >>> offloading support tha

Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()

On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross je...@nicira.com wrote: On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher jeffrey.t.kirs...@intel.com wrote: On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote: ndo_gso_check() was recently introduced to allow NICs to report the offloading support

Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()

On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher wrote: > On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote: >> ndo_gso_check() was recently introduced to allow NICs to report the >> offloading support that they have on a per-skb basis. Add an >> implementation for this driver which checks for

Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()

On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher jeffrey.t.kirs...@intel.com wrote: On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote: ndo_gso_check() was recently introduced to allow NICs to report the offloading support that they have on a per-skb basis. Add an implementation for this driver

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Tue, Dec 2, 2014 at 10:26 AM, Jesse Gross wrote: > On Mon, Dec 1, 2014 at 4:09 PM, Tom Herbert wrote: >> On Mon, Dec 1, 2014 at 3:53 PM, Jesse Gross wrote: >>> On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert wrote: >>>> On Mon, Dec 1, 2014 at 3:35 PM, Joe Stri

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Tue, Dec 2, 2014 at 10:26 AM, Jesse Gross je...@nicira.com wrote: On Mon, Dec 1, 2014 at 4:09 PM, Tom Herbert therb...@google.com wrote: On Mon, Dec 1, 2014 at 3:53 PM, Jesse Gross je...@nicira.com wrote: On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert therb...@google.com wrote: On Mon, Dec 1

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Mon, Dec 1, 2014 at 4:09 PM, Tom Herbert wrote: > On Mon, Dec 1, 2014 at 3:53 PM, Jesse Gross wrote: >> On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert wrote: >>> On Mon, Dec 1, 2014 at 3:35 PM, Joe Stringer wrote: >>>> On 21 November 2014 at 09:59, Joe Stringe

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Mon, Dec 1, 2014 at 4:09 PM, Tom Herbert therb...@google.com wrote: On Mon, Dec 1, 2014 at 3:53 PM, Jesse Gross je...@nicira.com wrote: On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert therb...@google.com wrote: On Mon, Dec 1, 2014 at 3:35 PM, Joe Stringer joestrin...@nicira.com wrote: On 21

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert wrote: > On Mon, Dec 1, 2014 at 3:35 PM, Joe Stringer wrote: >> On 21 November 2014 at 09:59, Joe Stringer wrote: >>> On 20 November 2014 16:19, Jesse Gross wrote: >>>> I don't know if we need to have the check at all fo

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert therb...@google.com wrote: On Mon, Dec 1, 2014 at 3:35 PM, Joe Stringer joestrin...@nicira.com wrote: On 21 November 2014 at 09:59, Joe Stringer joestrin...@nicira.com wrote: On 20 November 2014 16:19, Jesse Gross je...@nicira.com wrote: I don't know

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Thu, Nov 20, 2014 at 3:11 PM, Joe Stringer wrote: > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c > b/drivers/net/ethernet/intel/i40e/i40e_main.c > index c3a7f4a..2b01c8d 100644 > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c

Re: [PATCH net 2/5] i40e: Implement ndo_gso_check()

On Thu, Nov 20, 2014 at 11:16 AM, Joe Stringer wrote: > On Tuesday, November 04, 2014 15:45:22 Jesse Gross wrote: >> On Tue, Nov 4, 2014 at 1:56 PM, Joe Stringer wrote: >> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c >> > b/drivers/net/ethernet/intel/i40

Re: [PATCH net 2/5] i40e: Implement ndo_gso_check()

On Thu, Nov 20, 2014 at 11:16 AM, Joe Stringer joestrin...@nicira.com wrote: On Tuesday, November 04, 2014 15:45:22 Jesse Gross wrote: On Tue, Nov 4, 2014 at 1:56 PM, Joe Stringer joestrin...@nicira.com wrote: diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet

Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On Thu, Nov 20, 2014 at 3:11 PM, Joe Stringer joestrin...@nicira.com wrote: diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index c3a7f4a..2b01c8d 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++

Re: [PATCH net 0/5] Implement ndo_gso_check() for vxlan nics

On Thu, Nov 6, 2014 at 8:06 AM, Tom Herbert wrote: > On Wed, Nov 5, 2014 at 10:16 PM, Sathya Perla wrote: >>> -Original Message- >>> From: Tom Herbert [mailto:therb...@google.com] >>> >>> On Wed, Nov 5, 2014 at 6:15 PM, David Miller >>> wrote: >>> > From: Joe Stringer >>> > Date: Wed,

Re: [PATCH net 0/5] Implement ndo_gso_check() for vxlan nics

On Thu, Nov 6, 2014 at 8:06 AM, Tom Herbert therb...@google.com wrote: On Wed, Nov 5, 2014 at 10:16 PM, Sathya Perla sathya.pe...@emulex.com wrote: -Original Message- From: Tom Herbert [mailto:therb...@google.com] On Wed, Nov 5, 2014 at 6:15 PM, David Miller da...@davemloft.net

Re: [PATCH net 2/5] i40e: Implement ndo_gso_check()

On Tue, Nov 4, 2014 at 1:56 PM, Joe Stringer wrote: > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c > b/drivers/net/ethernet/intel/i40e/i40e_main.c > index c3a7f4a..21829b5 100644 > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c >

Re: [PATCH net 2/5] i40e: Implement ndo_gso_check()

On Tue, Nov 4, 2014 at 1:56 PM, Joe Stringer joestrin...@nicira.com wrote: diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index c3a7f4a..21829b5 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++

Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Fri, Apr 4, 2014 at 9:20 PM, wei zhang wrote: > At 2014-04-05 07:05:59,"Jesse Gross" wrote: >>On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang wrote: >>> >>> v2 -> v1: use the same logic of the gre_rcv() to distinguish which packet is >>> intended t

Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Fri, Apr 4, 2014 at 9:20 PM, wei zhang asuka@163.com wrote: At 2014-04-05 07:05:59,Jesse Gross je...@nicira.com wrote: On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang asuka@163.com wrote: v2 - v1: use the same logic of the gre_rcv() to distinguish which packet is intended to us! As a tip

Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang wrote: > When use gre vport, openvswitch register a gre_cisco_protocol but does not > supply a err_handler with it. The gre_cisco_err() in net/ipv4/gre_demux.c > expect > err_handler be provided with the gre_cisco_protocol implementation, and call >

Re: [PATCH v2] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Tue, Apr 1, 2014 at 5:23 PM, Wei Zhang asuka@163.com wrote: When use gre vport, openvswitch register a gre_cisco_protocol but does not supply a err_handler with it. The gre_cisco_err() in net/ipv4/gre_demux.c expect err_handler be provided with the gre_cisco_protocol implementation,

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Tue, Apr 1, 2014 at 8:24 AM, wei zhang wrote: > At 2014-04-01 08:49:53,"Jesse Gross" wrote: >>On Sun, Mar 30, 2014 at 5:12 AM, wei zhang wrote: >>> At 2014-03-29 06:02:25,"Jesse Gross" wrote: > >>> Maybe I misunderstand something? I think i

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Tue, Apr 1, 2014 at 8:24 AM, wei zhang asuka@163.com wrote: At 2014-04-01 08:49:53,Jesse Gross je...@nicira.com wrote: On Sun, Mar 30, 2014 at 5:12 AM, wei zhang asuka@163.com wrote: At 2014-03-29 06:02:25,Jesse Gross je...@nicira.com wrote: Maybe I misunderstand something? I think

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Sun, Mar 30, 2014 at 5:12 AM, wei zhang wrote: > At 2014-03-29 06:02:25,"Jesse Gross" wrote: > >>I'm not sure that rejecting all ICMP packets is the correct thing do >>here since it means that we could pass them onto a later caller even >>though they are i

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Sun, Mar 30, 2014 at 5:12 AM, wei zhang asuka@163.com wrote: At 2014-03-29 06:02:25,Jesse Gross je...@nicira.com wrote: I'm not sure that rejecting all ICMP packets is the correct thing do here since it means that we could pass them onto a later caller even though they are intended for us

Re: [PATCH] net/openvswitch: Use with RCU_INIT_POINTER(x, NULL) in vport-gre.c

On Sun, Mar 23, 2014 at 12:22 PM, Monam Agarwal wrote: > This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) > > The rcu_assign_pointer() ensures that the initialization of a structure > is carried out before storing a pointer to that structure. > And in the case of the

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Thu, Mar 27, 2014 at 2:56 PM, Wei Zhang wrote: > diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c > index a3d6951..d64c639 100644 > --- a/net/openvswitch/vport-gre.c > +++ b/net/openvswitch/vport-gre.c > @@ -110,6 +110,12 @@ static int gre_rcv(struct sk_buff *skb, >

Re: [PATCH] openvswitch: supply a dummy err_handler of gre_cisco_protocol to prevent kernel crash

On Thu, Mar 27, 2014 at 2:56 PM, Wei Zhang asuka@163.com wrote: diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c index a3d6951..d64c639 100644 --- a/net/openvswitch/vport-gre.c +++ b/net/openvswitch/vport-gre.c @@ -110,6 +110,12 @@ static int gre_rcv(struct sk_buff

Re: [PATCH] net/openvswitch: Use with RCU_INIT_POINTER(x, NULL) in vport-gre.c

On Sun, Mar 23, 2014 at 12:22 PM, Monam Agarwal monamagarwal...@gmail.com wrote: This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL) The rcu_assign_pointer() ensures that the initialization of a structure is carried out before storing a pointer to that structure.

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Fri, Jan 31, 2014 at 10:18 AM, Thomas Glanzmann wrote: >> Do you know if this happens with an older kernel or with a simpler topology? > > No, I don't. I just verified that the Ubuntu Mininet uses the > openvswitch kernel module from openvswitch and not the one that is > shipped with the

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Fri, Jan 31, 2014 at 10:18 AM, Thomas Glanzmann tho...@glanzmann.de wrote: Do you know if this happens with an older kernel or with a simpler topology? No, I don't. I just verified that the Ubuntu Mininet uses the openvswitch kernel module from openvswitch and not the one that is shipped

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Thu, Jan 30, 2014 at 6:33 PM, Thomas Glanzmann wrote: > Hello Jesse, > >> This looks like the kernel module included with upstream Linux instead >> of from OVS git, is that correct? > > coorect. > >> Can you please describe what you are doing instead of just giving your >> script? > > I

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Thu, Jan 30, 2014 at 6:33 PM, Thomas Glanzmann tho...@glanzmann.de wrote: Hello Jesse, This looks like the kernel module included with upstream Linux instead of from OVS git, is that correct? coorect. Can you please describe what you are doing instead of just giving your script? I

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Thu, Jan 30, 2014 at 12:44 PM, Thomas Glanzmann wrote: > Hello, > open vswitch git head with Linus tip OOPses for me reproducable when I > load the following mininet topology: This looks like the kernel module included with upstream Linux instead of from OVS git, is that correct? Can you

Re: [ovs-discuss] Linus GIT Head OOPs reproducable in open vswitch when running mininet topology

On Thu, Jan 30, 2014 at 12:44 PM, Thomas Glanzmann tho...@glanzmann.de wrote: Hello, open vswitch git head with Linus tip OOPses for me reproducable when I load the following mininet topology: This looks like the kernel module included with upstream Linux instead of from OVS git, is that

Re: [-next] openvswitch BUILD_BUG_ON failed

On Tue, Sep 3, 2013 at 11:55 PM, Geert Uytterhoeven wrote: > On Tue, Sep 3, 2013 at 11:44 PM, Jesse Gross wrote: >> On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven >> wrote: >>> On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross wrote: >>>> On Thu, Aug 29,

Re: [-next] openvswitch BUILD_BUG_ON failed

On Tue, Sep 3, 2013 at 11:55 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Tue, Sep 3, 2013 at 11:44 PM, Jesse Gross je...@nicira.com wrote: On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross je...@nicira.com

Re: [-next] openvswitch BUILD_BUG_ON failed

On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven wrote: > On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross wrote: >> On Thu, Aug 29, 2013 at 3:10 PM, David Miller wrote: >>> From: Jesse Gross >>> Date: Thu, 29 Aug 2013 14:42:22 -0700 >>> >>>> On

Re: [-next] openvswitch BUILD_BUG_ON failed

On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross je...@nicira.com wrote: On Thu, Aug 29, 2013 at 3:10 PM, David Miller da...@davemloft.net wrote: From: Jesse Gross je...@nicira.com Date: Thu, 29 Aug 2013 14:42:22 -0700

Re: [-next] openvswitch BUILD_BUG_ON failed

On Thu, Aug 29, 2013 at 3:10 PM, David Miller wrote: > From: Jesse Gross > Date: Thu, 29 Aug 2013 14:42:22 -0700 > >> On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven >> wrote: >>> However, I have some doubts about other alignment "enforcements": >

Re: [-next] openvswitch BUILD_BUG_ON failed

On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven wrote: > However, I have some doubts about other alignment "enforcements": > > "__aligned(__alignof__(long))" makes the whole struct aligned to the > alignment rule for "long": >1. This is only 2 bytes on m68k, i.e. != sizeof(long). >2.

Re: [-next] openvswitch BUILD_BUG_ON failed

On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: However, I have some doubts about other alignment enforcements: __aligned(__alignof__(long)) makes the whole struct aligned to the alignment rule for long: 1. This is only 2 bytes on m68k, i.e. != sizeof(long).

Re: [-next] openvswitch BUILD_BUG_ON failed

On Thu, Aug 29, 2013 at 3:10 PM, David Miller da...@davemloft.net wrote: From: Jesse Gross je...@nicira.com Date: Thu, 29 Aug 2013 14:42:22 -0700 On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: However, I have some doubts about other alignment enforcements

Re: linux-next: Tree for Jun 21 (netdev: openvswitch)

On Fri, Jun 21, 2013 at 8:22 AM, Randy Dunlap wrote: > On 06/21/13 01:17, Stephen Rothwell wrote: >> Hi all, >> >> Happy solstice! >> >> Changes since 20130620: >> > > when CONFIG_INET is not enabled: > > CC net/openvswitch/flow.o > In file included from net/openvswitch/flow.c:43:0: >

Re: linux-next: Tree for Jun 21 (netdev: openvswitch)

On Fri, Jun 21, 2013 at 8:22 AM, Randy Dunlap rdun...@infradead.org wrote: On 06/21/13 01:17, Stephen Rothwell wrote: Hi all, Happy solstice! Changes since 20130620: when CONFIG_INET is not enabled: CC net/openvswitch/flow.o In file included from net/openvswitch/flow.c:43:0:

Re: [PATCH v4 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

On Fri, Nov 16, 2012 at 12:35 AM, Shan Wei wrote: > Shan Wei said, at 2012/11/13 9:52: >> From: Shan Wei >> >> just use more faster this_cpu_ptr instead of per_cpu_ptr(p, >> smp_processor_id()); >> >> >> Signed-off-by: Shan Wei >> Reviewed

Re: [PATCH v4 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

-by: Christoph Lameter c...@linux.com Jesse Gross, would you like to pick it up to your tree? Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter wrote: > On Thu, 1 Nov 2012, Shan Wei wrote: > >> But for different field in same per-cpu variable, how to guarantee n_missed >> and n_hit are from same cpu? >> this_cpu_read(dp->stats_percpu->n_missed); >> [processor changed] >>

Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter c...@linux.com wrote: On Thu, 1 Nov 2012, Shan Wei wrote: But for different field in same per-cpu variable, how to guarantee n_missed and n_hit are from same cpu? this_cpu_read(dp-stats_percpu-n_missed); [processor changed]