Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net 1/2] net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
From: Or Gerlitz @ 2013-01-17 16:34 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: davem, netdev, amirv, jackm, yevgenyp, Yan Burman
In-Reply-To: <50F8279F.5030403@mellanox.com>

On 17/01/2013 18:32, Or Gerlitz wrote:
> (I don't really understand why mlx4_en_mac_to_u64() is done... its 
> horribly expensive...). matching 6 bytes can be done in 3 x86_64 
> instructions using the right helper (ether_addr_equal_64bits()) 

thanks for the heads up, we will fix.

Or.

^ permalink raw reply

* Re: [PATCH net 1/2] net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
From: Or Gerlitz @ 2013-01-17 16:32 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: davem, netdev, amirv, jackm, yevgenyp, Yan Burman
In-Reply-To: <1358439708.29723.55.camel@edumazet-glaptop>

On 17/01/2013 18:21, Eric Dumazet wrote:
> On Thu, 2013-01-17 at 17:30 +0200, Or Gerlitz wrote:
>> From: Yan Burman <yanb@mellanox.com>
>>
>> Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
>> same host" introduced a regression under which a bridge acting as vSwitch
>> whose uplink is an mlx4 Ethernet device become non-operative in native
>> (non sriov) mode. This happens since broadcast ARP requests sent by VMs
>> were loopback-ed by the HW and hence the bridge learned VM source MACs
>> on both the VM and the uplink ports.
>>
>> The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
>> configuration or when the device is in selftest.
>>
>> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
>> Signed-off-by: Yan Burman <yanb@mellanox.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>>   drivers/net/ethernet/mellanox/mlx4/en_tx.c |   13 +++++++++----
>>   1 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> index 2b799f4..6771b69 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> @@ -630,10 +630,15 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>>   		ring->tx_csum++;
>>   	}
>>   
>> -	/* Copy dst mac address to wqe */
>> -	ethh = (struct ethhdr *)skb->data;
>> -	tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
>> -	tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
>> +	if (mlx4_is_mfunc(mdev->dev) || priv->validate_loopback) {
>> +		/* Copy dst mac address to wqe. This allows loopback in eSwitch,
>> +		 * so that VFs and PF can communicate with each other
>> +		 */
>> +		ethh = (struct ethhdr *)skb->data;
>> +		tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
>> +		tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
>> +	}
>> +
>>   	/* Handle LSO (TSO) packets */
>>   	if (lso_header_size) {
>>   		/* Mark opcode as LSO */
> Isn't this bug could explain why mlx4 had to filter incoming frames ?

yes and no...

when in multi-function -- eSwitch mode we DO need to always put the DMAC 
in the TX WQE
since this is a hint for the HW to optionally conduct loopback (e.g if 
this DMAC is
registered with the HW for another VF). For net / 3.8 we wanted a pure 
bug fix 1st and most,
we have more patches that reduce checks related to loopback but they can 
have a better fit
to net-next.

Also, there's another patch set coming from Yan that enables bridge and 
macvlan over
VFs, this is new functionality, adding support to ndo_fdb entries and 
IFF_UNICAST_FLT,
will be submitted to net-next soon (next week I believe) too.

All in all, the check on the RX mode was intentionally not removed by this
patch and will be optimized and enhanced in more patches which are 
coming for
net-next.

Hope this makes things clearer.

Or.





>
> It seems you also could remove this chunk ?
>
> (I don't really understand why mlx4_en_mac_to_u64() is done... its
> horribly expensive...).
> matching 6 bytes can be done in 3 x86_64 instructions using the right
> helper (ether_addr_equal_64bits())
>
> vi +613 drivers/net/ethernet/mellanox/mlx4/en_rx.c
>
>                 ethh = (struct ethhdr *)(page_address(frags[0].page) +
>                                           frags[0].offset);
>                  s_mac = mlx4_en_mac_to_u64(ethh->h_source);
>
>                  /* If source MAC is equal to our own MAC and not performing
>                   * the selftest or flb disabled - drop the packet */
>                  if (s_mac == priv->mac &&
>                      !((dev->features & NETIF_F_LOOPBACK) ||
>                        priv->validate_loopback))
>                          goto next;
>
>

^ permalink raw reply

* Re: [PATCH net 1/2] net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
From: Eric Dumazet @ 2013-01-17 16:21 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: davem, netdev, amirv, jackm, yevgenyp, Yan Burman
In-Reply-To: <1358436643-1326-2-git-send-email-ogerlitz@mellanox.com>

On Thu, 2013-01-17 at 17:30 +0200, Or Gerlitz wrote:
> From: Yan Burman <yanb@mellanox.com>
> 
> Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
> same host" introduced a regression under which a bridge acting as vSwitch
> whose uplink is an mlx4 Ethernet device become non-operative in native
> (non sriov) mode. This happens since broadcast ARP requests sent by VMs
> were loopback-ed by the HW and hence the bridge learned VM source MACs
> on both the VM and the uplink ports.
> 
> The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
> configuration or when the device is in selftest.
> 
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Yan Burman <yanb@mellanox.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
>  drivers/net/ethernet/mellanox/mlx4/en_tx.c |   13 +++++++++----
>  1 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 2b799f4..6771b69 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -630,10 +630,15 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>  		ring->tx_csum++;
>  	}
>  
> -	/* Copy dst mac address to wqe */
> -	ethh = (struct ethhdr *)skb->data;
> -	tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
> -	tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
> +	if (mlx4_is_mfunc(mdev->dev) || priv->validate_loopback) {
> +		/* Copy dst mac address to wqe. This allows loopback in eSwitch,
> +		 * so that VFs and PF can communicate with each other
> +		 */
> +		ethh = (struct ethhdr *)skb->data;
> +		tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
> +		tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
> +	}
> +
>  	/* Handle LSO (TSO) packets */
>  	if (lso_header_size) {
>  		/* Mark opcode as LSO */

Isn't this bug could explain why mlx4 had to filter incoming frames ?

It seems you also could remove this chunk ?

(I don't really understand why mlx4_en_mac_to_u64() is done... its
horribly expensive...). 
matching 6 bytes can be done in 3 x86_64 instructions using the right
helper (ether_addr_equal_64bits())

vi +613 drivers/net/ethernet/mellanox/mlx4/en_rx.c

               ethh = (struct ethhdr *)(page_address(frags[0].page) +
                                         frags[0].offset);
                s_mac = mlx4_en_mac_to_u64(ethh->h_source);

                /* If source MAC is equal to our own MAC and not performing
                 * the selftest or flb disabled - drop the packet */
                if (s_mac == priv->mac &&
                    !((dev->features & NETIF_F_LOOPBACK) ||
                      priv->validate_loopback))
                        goto next;

^ permalink raw reply

* Re: [PATCH net-next] net/mlx4_en: remove redundant code
From: Amir Vadai @ 2013-01-17 16:22 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David S. Miller, netdev, Or Gerlitz, Yevgeny Petrilin,
	Eugenia Emantayev
In-Reply-To: <1358436367.29723.49.camel@edumazet-glaptop>

On 17/01/2013 17:26, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> remove redundant code from build_inline_wqe()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> Amir, reviewing this driver, it looks like following could be done,
> could you test the patch for me ?
>
> Thanks
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 2b799f4..16af338 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -515,10 +515,6 @@ static void build_inline_wqe(struct mlx4_en_tx_desc *tx_desc, struct sk_buff *sk
>   		wmb();
>   		inl->byte_count = cpu_to_be32(1 << 31 | (skb->len - spc));
>   	}
> -	tx_desc->ctrl.vlan_tag = cpu_to_be16(*vlan_tag);
> -	tx_desc->ctrl.ins_vlan = MLX4_WQE_CTRL_INS_VLAN *
> -		(!!vlan_tx_tag_present(skb));
> -	tx_desc->ctrl.fence_size = (real_size / 16) & 0x3f;
>   }
>
>   u16 mlx4_en_select_queue(struct net_device *dev, struct sk_buff *skb)
>
>

It seems that you're right.

I'm currently out of office - will check it on Sunday.

Thanks,
Amir

^ permalink raw reply

* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: Hannes Frederic Sowa @ 2013-01-17 16:17 UTC (permalink / raw)
  To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <50F81C4B.3050406@linux-ipv6.org>

On Fri, Jan 18, 2013 at 12:44:11AM +0900, YOSHIFUJI Hideaki wrote:
> Hannes Frederic Sowa wrote:
> > This patch adds anti-spoofing checks in sit.c as specified in RFC3964
> > section 5.2 for 6to4 and RFC5969 section 12 for 6rd. I left out the
> > checks which could easily be implemented with netfilter.
> > 
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
> >  net/ipv6/sit.c | 27 +++++++++++++++++++++++++--
> >  1 file changed, 25 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index cfba99b..2b4c15a 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -590,6 +590,22 @@ out:
> >  	return err;
> >  }
> >  
> > +static int sit_chksrc(struct ip_tunnel *tunnel, const __be32 *addr,
> > +		const struct in6_addr *addr6)
> > +{
> > +#ifdef CONFIG_IPV6_SIT_6RD
> > +	if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
> > +				tunnel->ip6rd.prefixlen) &&
> > +		memcmp(addr, &addr6->s6_addr16[1], 4))
> > +		return 0;
> > +#else
> > +	if (addr6->s6_addr16[0] == htons(0x2002) &&
> > +		memcmp(addr, &addr6->s6_addr16[1], 4))
> > +		return 0;
> > +#endif
> > +	return 1;
> >
> 
> It seems wrong.  Check should be done for
> - inner source prefix

I intentionally skipped this check because it could be easily checked
with netfilter (after decapsulation) and I am a bit afraid breaking
already working setups with non-standard prefixes. Do you think I should
add this check anyway?

> - embedded source with relay_prefix.

I'll use try_6rd to extract the ipv4 address and check it against the
outer address. I will check this later if I have access to my test setup.

> - inner destination prefix.
>
> Note: embedded destination is not being checked.

Also left these checks out because of the same reasons I stated above. Should
they be added?

Thanks for the review!

^ permalink raw reply

* Re: [net-next 04/14] e1000e: add support for IEEE-1588 PTP
From: Stephen Hemminger @ 2013-01-17 15:56 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann, Richard Cochran
In-Reply-To: <1358422519-20981-5-git-send-email-jeffrey.t.kirsher@intel.com>

On Thu, 17 Jan 2013 03:35:09 -0800
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:

> +static struct ptp_clock_info e1000e_ptp_clock_info = {

Should be static const since it is immutable and contains function pointers.

^ permalink raw reply

* Re: [patch net-next] team: do not use -ENOENT
From: Stephen Hemminger @ 2013-01-17 15:51 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <1358418300-2346-1-git-send-email-jiri@resnulli.us>

On Thu, 17 Jan 2013 11:25:00 +0100
Jiri Pirko <jiri@resnulli.us> wrote:

> Since this error code means "No such file or directory", change this
> value in team driver to ones which make more sense.
> 
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
>  drivers/net/team/team.c                   | 4 ++--
>  drivers/net/team/team_mode_activebackup.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> index 70d5d6b..3d7cf6e 100644
> --- a/drivers/net/team/team.c
> +++ b/drivers/net/team/team.c
> @@ -1128,7 +1128,7 @@ static int team_port_del(struct team *team, struct net_device *port_dev)
>  	if (!port || !team_port_find(team, port)) {
>  		netdev_err(dev, "Device %s does not act as a port of this team\n",
>  			   portname);
> -		return -ENOENT;
> +		return -ENODEV;
>  	}
>  
>  	__team_option_inst_mark_removed_port(team, port);
> @@ -2320,7 +2320,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
>  			list_add(&opt_inst->tmp_list, &opt_inst_list);
>  		}
>  		if (!opt_found) {
> -			err = -ENOENT;
> +			err = -EINVAL;
>  			goto team_put;
>  		}
>  	}
> diff --git a/drivers/net/team/team_mode_activebackup.c b/drivers/net/team/team_mode_activebackup.c
> index 6262b4d..2792e13 100644
> --- a/drivers/net/team/team_mode_activebackup.c
> +++ b/drivers/net/team/team_mode_activebackup.c
> @@ -81,7 +81,7 @@ static int ab_active_port_set(struct team *team, struct team_gsetter_ctx *ctx)
>  			return 0;
>  		}
>  	}
> -	return -ENOENT;
> +	return -ENODEV;
>  }
>  
>  static const struct team_option ab_options[] = {

To be pedantic.
Changing errno's means effectively changing the ABI.
Linus has already rejected similar patches in other areas.

^ permalink raw reply

* Re: ip6_dst_lookup_tail oops
From: Dave Jones @ 2013-01-17 15:25 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20130116145507.GA12244@redhat.com>

On Wed, Jan 16, 2013 at 09:55:07AM -0500, Dave Jones wrote:

 > BUG: unable to handle kernel NULL pointer dereference at 000000000000017e
 > IP: [<ffffffff81626308>] ip6_dst_lookup_tail+0xe8/0x200
 > RIP: 0010:[<ffffffff81626308>]  [<ffffffff81626308>] ip6_dst_lookup_tail+0xe8/0x200
 > RAX: 0000000000000011 RBX: 0000000000000000 RCX: 0000000000000000
 > ..
 > Call Trace:
 >  [<ffffffff816266cb>] ip6_sk_dst_lookup_flow+0xcb/0x1b0
 >  [<ffffffff8164803e>] udpv6_sendmsg+0x66e/0xb80
 >  [<ffffffff815e6391>] inet_sendmsg+0x111/0x220
 >  [<ffffffff81547220>] sock_sendmsg+0xb0/0xe0
 >  [<ffffffff815486bc>] __sys_sendmsg+0x3ac/0x3c0
 >  [<ffffffff8154afb9>] sys_sendmsg+0x49/0x90
 >  [<ffffffff816a6802>] system_call_fastpath+0x16/0x1b
 > 
 >    0:	f6 80 6d 01 00 00 de 	testb  $0xde,0x16d(%rax)
 >    7:	75 b9                	jne    0xffffffffffffffc2
 >    9:	48 8b 56 18          	mov    0x18(%rsi),%rdx
 >    d:	49 8d 75 24          	lea    0x24(%r13),%rsi
 >   11:	b9                   	.byte 0xb9
 >   12:	01 00                	add    %eax,(%rax)
 > 	...
 > 
 > This looks like the GPF in this function I reported last September.
 > http://www.spinics.net/lists/netdev/msg211894.html
 > 
 > In those reports, I ended up with an rt->n == 0x8000000000000011,
 > but this time, it's just 0x11.

Now I've hit it with rt->n = 2000000000000010. So I'm starting to
think this is getting passed in directly from userspace somehow, as
these values look like the output of my 'set a few random bits' routine
that sometimes gets called for params.

I'm having trouble mapping a corrupt sendmsg parameter to a messed up rt->n though.

Any clues ?

	Dave

^ permalink raw reply

* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: YOSHIFUJI Hideaki @ 2013-01-17 15:44 UTC (permalink / raw)
  To: netdev, hannes; +Cc: YOSHIFUJI Hideaki
In-Reply-To: <20130117033258.GA23782@order.stressinduktion.org>

Hannes Frederic Sowa wrote:
> This patch adds anti-spoofing checks in sit.c as specified in RFC3964
> section 5.2 for 6to4 and RFC5969 section 12 for 6rd. I left out the
> checks which could easily be implemented with netfilter.
> 
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
>  net/ipv6/sit.c | 27 +++++++++++++++++++++++++--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index cfba99b..2b4c15a 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -590,6 +590,22 @@ out:
>  	return err;
>  }
>  
> +static int sit_chksrc(struct ip_tunnel *tunnel, const __be32 *addr,
> +		const struct in6_addr *addr6)
> +{
> +#ifdef CONFIG_IPV6_SIT_6RD
> +	if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
> +				tunnel->ip6rd.prefixlen) &&
> +		memcmp(addr, &addr6->s6_addr16[1], 4))
> +		return 0;
> +#else
> +	if (addr6->s6_addr16[0] == htons(0x2002) &&
> +		memcmp(addr, &addr6->s6_addr16[1], 4))
> +		return 0;
> +#endif
> +	return 1;
>

It seems wrong.  Check should be done for
- inner source prefix
- embedded source with relay_prefix.
- inner destination prefix.

Note: embedded destination is not being checked.

--yoshfuji

^ permalink raw reply

* Re: [net-next 12/14] igb: Add mechanism for detecting latched hardware Rx timestamp
From: Richard Cochran @ 2013-01-17 15:38 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1358422519-20981-13-git-send-email-jeffrey.t.kirsher@intel.com>

On Thu, Jan 17, 2013 at 03:35:17AM -0800, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
> 
> Add a check against possible Rx timestamp freezing in the hardware via
> watchdog mechanism. This situation can occur when an Rx timestamp has been
> latched, but the packet has been dropped because the Rx ring is full.

Does this also need fixing in stable?

The igb patches look okay to me.

Acked-by: Richard Cochran <richardcochran@gmail.com>

^ permalink raw reply

* [PATCH 1/1] phy/marvell: remove fiber/copper autoselect on 88e1111
From: Stef van Os @ 2013-01-17 15:36 UTC (permalink / raw)
  To: chohnstaedt, davem, srinivas.kandagatla; +Cc: netdev, linux-kernel, Stef van Os

Remove the code that always enables copper/fiber autoselect,
ignoring the DIS_FC strapping pin. The default value for this
register is autoselect on anyway, and if you explicitly disable
autoselect via strapping you probably really don't want
autoselect.

Signed-off-by: Stef van Os <stef.van.os@prodrive.nl>
---
 drivers/net/phy/marvell.c |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 5d2a3f2..22dec9c 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -353,15 +353,6 @@ static int m88e1111_config_init(struct phy_device *phydev)
 	int err;
 	int temp;
 
-	/* Enable Fiber/Copper auto selection */
-	temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
-	temp &= ~MII_M1111_HWCFG_FIBER_COPPER_AUTO;
-	phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
-
-	temp = phy_read(phydev, MII_BMCR);
-	temp |= BMCR_RESET;
-	phy_write(phydev, MII_BMCR, temp);
-
 	if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
 	    (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
 	    (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
-- 
1.7.2.5

^ permalink raw reply related

* Re: [net-next 04/14] e1000e: add support for IEEE-1588 PTP
From: Richard Cochran @ 2013-01-17 15:35 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1358422519-20981-5-git-send-email-jeffrey.t.kirsher@intel.com>

On Thu, Jan 17, 2013 at 03:35:09AM -0800, Jeff Kirsher wrote:

> +static struct ptp_clock_info e1000e_ptp_clock_info = {
> +	.owner		= THIS_MODULE,

small nit: better to use a static string for .name here than ...

> +	.n_alarm	= 0,
> +	.n_ext_ts	= 0,
> +	.n_per_out	= 0,
> +	.pps		= 0,
> +	.adjfreq	= e1000e_phc_adjfreq,
> +	.adjtime	= e1000e_phc_adjtime,
> +	.gettime	= e1000e_phc_gettime,
> +	.settime	= e1000e_phc_settime,
> +	.enable		= e1000e_phc_enable,
> +};
> +
> +/**
> + * e1000e_ptp_init - initialize PTP for devices which support it
> + * @adapter: board private structure
> + *
> + * This function performs the required steps for enabling PTP support.
> + * If PTP support has already been loaded it simply calls the cyclecounter
> + * init routine and exits.
> + **/
> +void e1000e_ptp_init(struct e1000_adapter *adapter)
> +{
> +	struct e1000_hw *hw = &adapter->hw;
> +
> +	adapter->ptp_clock = NULL;
> +
> +	if (!(adapter->flags & FLAG_HAS_HW_TIMESTAMP))
> +		return;
> +
> +	adapter->ptp_clock_info = e1000e_ptp_clock_info;
> +
> +	snprintf(adapter->ptp_clock_info.name,
> +		 sizeof(adapter->ptp_clock_info.name), "%pm",
> +		 adapter->netdev->perm_addr);

... putting any kind of address here. After some back and forth,
discussing what the 'name' field should be, we decided on

 * @name:      A short "friendly name" to identify the clock and to
 *             help distinguish PHY based devices from MAC based ones.
 *             The string is not meant to be a unique id.

and most other drivers put the name of the driver here.

Other than that, this new driver looks good to me. I'll try it out
soon.

Acked-by: Richard Cochran <richardcochran@gmail.com>

^ permalink raw reply

* [PATCH net 0/2] net/mlx4: two virtualization bug fixes
From: Or Gerlitz @ 2013-01-17 15:30 UTC (permalink / raw)
  To: davem; +Cc: netdev, amirv, jackm, yevgenyp, Or Gerlitz

Hi Dave, 

These are two fixes to driver bugs which were introduced during the integration 
of the SRIOV patches, would love see them going to -stable too.

Or.


Or Gerlitz (1):
  net/mlx4_core: Set number of msix vectors under SRIOV mode to
    firmware defaults

Yan Burman (1):
  net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode

 drivers/net/ethernet/mellanox/mlx4/en_tx.c |   13 +++++++++----
 drivers/net/ethernet/mellanox/mlx4/main.c  |   11 ++---------
 2 files changed, 11 insertions(+), 13 deletions(-)

^ permalink raw reply

* Re: [BUG] "sleeping in invalid" in dev_change_name()
From: Guennadi Liakhovetski @ 2013-01-17 15:32 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: netdev, David S. Miller
In-Reply-To: <1358433002.29723.14.camel@edumazet-glaptop>

Hi Eric

On Thu, 17 Jan 2013, Eric Dumazet wrote:

> On Thu, 2013-01-17 at 11:22 +0100, Guennadi Liakhovetski wrote:
> > Hi, getting a BUG dump below from a wireless driver, is probably not 
> > driver specific. Just not seeing it normally, because in most cases the 
> > name is either the same, or the interface is already up and you get a 
> > -EBUSY back.
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> > 
> > [   63.789062] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
> > [   63.789062] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> > [   63.804687] mmc1: queuing unknown CIS tuple 0x80 (9 bytes)
> > [   63.804687] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> > [   63.812500] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> > [   63.820312] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> > [   63.820312] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> > [   63.828125] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
> > [   63.835937] mmc1: queuing unknown CIS tuple 0x80 (9 bytes)
> > [   63.843750] mmc1: new SDIO card at address 0001
> > [   63.851562] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> > [   63.851562] ssb: Found chip with id 0x4318, rev 0x02 and package 0x00
> > [   63.867187] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> > [   63.875000] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
> > [   63.890625] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> > [   63.890625] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> > [   63.906250] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> > [   63.960937] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> > [   64.015625] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> > [   64.187500] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > [   64.203125] BUG: sleeping function called from invalid context at .../linux/mm/slab.c:3179
> > [   64.210937] in_atomic(): 1, irqs_disabled(): 0, pid: 940, name: udevd
> > [   64.218750] Backtrace: 
> > [   64.218750] [<c0012724>] (dump_backtrace+0x0/0x110) from [<c0267c80>] (dump_stack+0x18/0x1c)
> > [   64.226562]  r6:cf1c6bc0 r5:000000d0 r4:cf000080 r3:60000013
> > [   64.234375] [<c0267c68>] (dump_stack+0x0/0x1c) from [<c004493c>] (__might_sleep+0xec/0x10c)
> > [   64.242187] [<c0044850>] (__might_sleep+0x0/0x10c) from [<c008f988>] (__kmalloc_track_caller+0x80/0x188)
> > [   64.250000] [<c008f908>] (__kmalloc_track_caller+0x0/0x188) from [<c0074dac>] (kstrdup+0x38/0x54)
> > [   64.257812]  r7:000000d0 r6:cf1c6bc0 r5:00000006 r4:c0199af4
> > [   64.257812] [<c0074d74>] (kstrdup+0x0/0x54) from [<c0199af4>] (device_rename+0x34/0xa4)
> > [   64.265625]  r7:c03ca0c0 r6:cf4b9000 r5:cf4b9000 r4:cf4b9218
> > [   64.273437] [<c0199ac0>] (device_rename+0x0/0xa4) from [<c01eb9f4>] (dev_change_name+0xdc/0x274)
> > [   64.281250]  r7:c03ca0c0 r6:00000000 r5:cf4b9000 r4:cf504000
> > [   64.289062] [<c01eb918>] (dev_change_name+0x0/0x274) from [<c01ebd5c>] (dev_ifsioc+0x1d0/0x34c)
> > [   64.296875] [<c01ebb8c>] (dev_ifsioc+0x0/0x34c) from [<c01ec4a4>] (dev_ioctl+0x5cc/0x748)
> > [   64.304687]  r7:cf505e70 r6:00000000 r5:00008923 r4:bea7e220
> > [   64.312500] [<c01ebed8>] (dev_ioctl+0x0/0x748) from [<c01d8954>] (sock_ioctl+0x270/0x2a4)
> > [   64.320312] [<c01d86e4>] (sock_ioctl+0x0/0x2a4) from [<c00a0f84>] (vfs_ioctl+0x28/0x40)
> > [   64.328125]  r6:00000003 r5:cf1d4340 r4:bea7e220 r3:c01d86e4
> > [   64.335937] [<c00a0f5c>] (vfs_ioctl+0x0/0x40) from [<c00a1738>] (do_vfs_ioctl+0x5b0/0x5fc)
> > [   64.343750] [<c00a1188>] (do_vfs_ioctl+0x0/0x5fc) from [<c00a17c8>] (sys_ioctl+0x44/0x64)
> > [   64.351562] [<c00a1784>] (sys_ioctl+0x0/0x64) from [<c000ec00>] (ret_fast_syscall+0x0/0x30)
> > [   64.359375]  r8:c000eda8 r7:00000036 r6:b6fb7d98 r5:b6fcf1a8 r4:b6fcf168
> > [   84.742187] b43-phy0: Loading OpenSource firmware version 410.31754
> > [   84.742187] b43-phy0: Hardware crypto acceleration not supported by firmware
> > --
> 
> Hard to say, you forgot to tell what is the kernel version.

Sorry, it is 3.8-rc1 based.

> I guess you didnt upgrade your tree recently ?
> 
> # git describe --contains 30e6c9fa93cf3dbc7cc6df1d748ad25e4264545a
> v3.8-rc2~19^2~17

This patch wasn't there, it does seem to fix the problem, thanks!

Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

^ permalink raw reply

* [PATCH net 1/2] net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
From: Or Gerlitz @ 2013-01-17 15:30 UTC (permalink / raw)
  To: davem; +Cc: netdev, amirv, jackm, yevgenyp, Yan Burman
In-Reply-To: <1358436643-1326-1-git-send-email-ogerlitz@mellanox.com>

From: Yan Burman <yanb@mellanox.com>

Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
same host" introduced a regression under which a bridge acting as vSwitch
whose uplink is an mlx4 Ethernet device become non-operative in native
(non sriov) mode. This happens since broadcast ARP requests sent by VMs
were loopback-ed by the HW and hence the bridge learned VM source MACs
on both the VM and the uplink ports.

The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
configuration or when the device is in selftest.

Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx4/en_tx.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 2b799f4..6771b69 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -630,10 +630,15 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
 		ring->tx_csum++;
 	}
 
-	/* Copy dst mac address to wqe */
-	ethh = (struct ethhdr *)skb->data;
-	tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
-	tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
+	if (mlx4_is_mfunc(mdev->dev) || priv->validate_loopback) {
+		/* Copy dst mac address to wqe. This allows loopback in eSwitch,
+		 * so that VFs and PF can communicate with each other
+		 */
+		ethh = (struct ethhdr *)skb->data;
+		tx_desc->ctrl.srcrb_flags16[0] = get_unaligned((__be16 *)ethh->h_dest);
+		tx_desc->ctrl.imm = get_unaligned((__be32 *)(ethh->h_dest + 2));
+	}
+
 	/* Handle LSO (TSO) packets */
 	if (lso_header_size) {
 		/* Mark opcode as LSO */
-- 
1.7.1

^ permalink raw reply related

* [PATCH net 2/2] net/mlx4_core: Set number of msix vectors under SRIOV mode to firmware defaults
From: Or Gerlitz @ 2013-01-17 15:30 UTC (permalink / raw)
  To: davem; +Cc: netdev, amirv, jackm, yevgenyp, Or Gerlitz
In-Reply-To: <1358436643-1326-1-git-send-email-ogerlitz@mellanox.com>

The lines

	if (mlx4_is_mfunc(dev)) {
		nreq = 2;
	} else {

which hard code the number of requested msi-x vectors under multi-function
mode to two can be removed completely, since the firmware sets num_eqs and
reserved_eqs appropriately Thus, the code line:

	nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs, nreq);

is by itself sufficient and correct for all cases. Currently, for mfunc
mode num_eqs = 32 and reserved_eqs = 28, hence four vectors will be enabled.

This triples (one vector is used for the async events and commands EQ) the
horse power provided for processing of incoming packets on netdev RSS scheme,
IO initiators/targets commands processing flows, etc.

Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx4/main.c |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index e1bafff..a6542d7 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -1790,15 +1790,8 @@ static void mlx4_enable_msi_x(struct mlx4_dev *dev)
 	int i;
 
 	if (msi_x) {
-		/* In multifunction mode each function gets 2 msi-X vectors
-		 * one for data path completions anf the other for asynch events
-		 * or command completions */
-		if (mlx4_is_mfunc(dev)) {
-			nreq = 2;
-		} else {
-			nreq = min_t(int, dev->caps.num_eqs -
-				     dev->caps.reserved_eqs, nreq);
-		}
+		nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs,
+			     nreq);
 
 		entries = kcalloc(nreq, sizeof *entries, GFP_KERNEL);
 		if (!entries)
-- 
1.7.1

^ permalink raw reply related

* [PATCH net-next] net/mlx4_en: remove redundant code
From: Eric Dumazet @ 2013-01-17 15:26 UTC (permalink / raw)
  To: Amir Vadai
  Cc: David S. Miller, netdev, Or Gerlitz, Yevgeny Petrilin,
	Eugenia Emantayev
In-Reply-To: <1358432538.29723.8.camel@edumazet-glaptop>

From: Eric Dumazet <edumazet@google.com>

remove redundant code from build_inline_wqe()

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Amir, reviewing this driver, it looks like following could be done,
could you test the patch for me ?

Thanks

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 2b799f4..16af338 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -515,10 +515,6 @@ static void build_inline_wqe(struct mlx4_en_tx_desc *tx_desc, struct sk_buff *sk
 		wmb();
 		inl->byte_count = cpu_to_be32(1 << 31 | (skb->len - spc));
 	}
-	tx_desc->ctrl.vlan_tag = cpu_to_be16(*vlan_tag);
-	tx_desc->ctrl.ins_vlan = MLX4_WQE_CTRL_INS_VLAN *
-		(!!vlan_tx_tag_present(skb));
-	tx_desc->ctrl.fence_size = (real_size / 16) & 0x3f;
 }
 
 u16 mlx4_en_select_queue(struct net_device *dev, struct sk_buff *skb)

^ permalink raw reply related

* RE: [PATCH net] net/vxlan: Use the underlying device index when joining/leaving multicast groups
From: Yan Burman @ 2013-01-17 15:19 UTC (permalink / raw)
  To: Bernhard Schmidt; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <20130114004652.GA11597@fliwatuet.svr02.mucip.net>


> -----Original Message-----
> From: Bernhard Schmidt [mailto:berni@birkenwald.de]
> Sent: Monday, January 14, 2013 02:48
> To: Yan Burman
> Subject: Re: [PATCH net] net/vxlan: Use the underlying device index when
> joining/leaving multicast groups
> 
> In gmane.linux.network, Yan Burman wrote:
> 
> Hello,
> 
> thanks! That fixes my issue. Could you please submit this to -stable?
> 

>From my understanding David is the one submitting to -stable.
I can send it to -stable assuming it's ok with David.

Yan

> Thanks,
> Bernhard
> 
> > The socket calls from vxlan to join/leave multicast group aren't using
> > the index of the underlying device, as a result the stack uses the
> > first interface that is up. This results in vxlan being non functional
> > over a device which isn't the 1st to be up.
> > Fix this by providing the iflink field to the vxlan instance to the
> > multicast calls.
> >
> > Signed-off-by: Yan Burman <yanb@mellanox.com>
> > ---
> >  drivers/net/vxlan.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index
> > 3b3fdf6..40f2cc1 100644
> > --- a/drivers/net/vxlan.c
> > +++ b/drivers/net/vxlan.c
> > @@ -505,7 +505,8 @@ static int vxlan_join_group(struct net_device *dev)
> >  	struct vxlan_net *vn = net_generic(dev_net(dev), vxlan_net_id);
> >  	struct sock *sk = vn->sock->sk;
> >  	struct ip_mreqn mreq = {
> > -		.imr_multiaddr.s_addr = vxlan->gaddr,
> > +		.imr_multiaddr.s_addr	= vxlan->gaddr,
> > +		.imr_ifindex		= vxlan->link,
> >  	};
> >  	int err;
> >
> > @@ -532,7 +533,8 @@ static int vxlan_leave_group(struct net_device
> *dev)
> >  	int err = 0;
> >  	struct sock *sk = vn->sock->sk;
> >  	struct ip_mreqn mreq = {
> > -		.imr_multiaddr.s_addr = vxlan->gaddr,
> > +		.imr_multiaddr.s_addr	= vxlan->gaddr,
> > +		.imr_ifindex		= vxlan->link,
> >  	};
> >
> >  	/* Only leave group when last vxlan is done. */
> > --
> > 1.7.11.3
> >

^ permalink raw reply

* Re: [PATCH net-next] bnx2x: fix GRO parameters
From: Eric Dumazet @ 2013-01-17 14:33 UTC (permalink / raw)
  To: Yuval Mintz; +Cc: davem, netdev, eilong, ariele
In-Reply-To: <1358429181-3348-1-git-send-email-yuvalmin@broadcom.com>

On Thu, 2013-01-17 at 15:26 +0200, Yuval Mintz wrote:
> bnx2x does an internal GRO pass but doesn't provide gso_segs, thus
> breaking qdisc_pkt_len_init() in case ingress qdisc is used.
> 
> We store gso_segs in NAPI_GRO_CB(skb)->count, where tcp_gro_complete()
> expects to find the number of aggregated segments.
> 
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> ---
> This is Eric Dumazet's patch with slight semantic modifications.
> Eric - Do you want to put your ack or signoff on this patch?
> 

Sure, thanks !

Signed-off-by: Eric Dumazet <edumazet@google.com>

> Dave - Please apply this to 'net-next' afterwards.
> 
> Thanks,
> Yuval Mintz

^ permalink raw reply

* Re: [BUG] "sleeping in invalid" in dev_change_name()
From: Eric Dumazet @ 2013-01-17 14:30 UTC (permalink / raw)
  To: Guennadi Liakhovetski; +Cc: netdev, David S. Miller
In-Reply-To: <Pine.LNX.4.64.1301171114150.30897@axis700.grange>

On Thu, 2013-01-17 at 11:22 +0100, Guennadi Liakhovetski wrote:
> Hi, getting a BUG dump below from a wireless driver, is probably not 
> driver specific. Just not seeing it normally, because in most cases the 
> name is either the same, or the interface is already up and you get a 
> -EBUSY back.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 
> [   63.789062] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
> [   63.789062] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [   63.804687] mmc1: queuing unknown CIS tuple 0x80 (9 bytes)
> [   63.804687] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [   63.812500] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [   63.820312] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
> [   63.820312] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
> [   63.828125] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
> [   63.835937] mmc1: queuing unknown CIS tuple 0x80 (9 bytes)
> [   63.843750] mmc1: new SDIO card at address 0001
> [   63.851562] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [   63.851562] ssb: Found chip with id 0x4318, rev 0x02 and package 0x00
> [   63.867187] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> [   63.875000] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
> [   63.890625] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> [   63.890625] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> [   63.906250] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> [   63.960937] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
> [   64.015625] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> [   64.187500] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [   64.203125] BUG: sleeping function called from invalid context at .../linux/mm/slab.c:3179
> [   64.210937] in_atomic(): 1, irqs_disabled(): 0, pid: 940, name: udevd
> [   64.218750] Backtrace: 
> [   64.218750] [<c0012724>] (dump_backtrace+0x0/0x110) from [<c0267c80>] (dump_stack+0x18/0x1c)
> [   64.226562]  r6:cf1c6bc0 r5:000000d0 r4:cf000080 r3:60000013
> [   64.234375] [<c0267c68>] (dump_stack+0x0/0x1c) from [<c004493c>] (__might_sleep+0xec/0x10c)
> [   64.242187] [<c0044850>] (__might_sleep+0x0/0x10c) from [<c008f988>] (__kmalloc_track_caller+0x80/0x188)
> [   64.250000] [<c008f908>] (__kmalloc_track_caller+0x0/0x188) from [<c0074dac>] (kstrdup+0x38/0x54)
> [   64.257812]  r7:000000d0 r6:cf1c6bc0 r5:00000006 r4:c0199af4
> [   64.257812] [<c0074d74>] (kstrdup+0x0/0x54) from [<c0199af4>] (device_rename+0x34/0xa4)
> [   64.265625]  r7:c03ca0c0 r6:cf4b9000 r5:cf4b9000 r4:cf4b9218
> [   64.273437] [<c0199ac0>] (device_rename+0x0/0xa4) from [<c01eb9f4>] (dev_change_name+0xdc/0x274)
> [   64.281250]  r7:c03ca0c0 r6:00000000 r5:cf4b9000 r4:cf504000
> [   64.289062] [<c01eb918>] (dev_change_name+0x0/0x274) from [<c01ebd5c>] (dev_ifsioc+0x1d0/0x34c)
> [   64.296875] [<c01ebb8c>] (dev_ifsioc+0x0/0x34c) from [<c01ec4a4>] (dev_ioctl+0x5cc/0x748)
> [   64.304687]  r7:cf505e70 r6:00000000 r5:00008923 r4:bea7e220
> [   64.312500] [<c01ebed8>] (dev_ioctl+0x0/0x748) from [<c01d8954>] (sock_ioctl+0x270/0x2a4)
> [   64.320312] [<c01d86e4>] (sock_ioctl+0x0/0x2a4) from [<c00a0f84>] (vfs_ioctl+0x28/0x40)
> [   64.328125]  r6:00000003 r5:cf1d4340 r4:bea7e220 r3:c01d86e4
> [   64.335937] [<c00a0f5c>] (vfs_ioctl+0x0/0x40) from [<c00a1738>] (do_vfs_ioctl+0x5b0/0x5fc)
> [   64.343750] [<c00a1188>] (do_vfs_ioctl+0x0/0x5fc) from [<c00a17c8>] (sys_ioctl+0x44/0x64)
> [   64.351562] [<c00a1784>] (sys_ioctl+0x0/0x64) from [<c000ec00>] (ret_fast_syscall+0x0/0x30)
> [   64.359375]  r8:c000eda8 r7:00000036 r6:b6fb7d98 r5:b6fcf1a8 r4:b6fcf168
> [   84.742187] b43-phy0: Loading OpenSource firmware version 410.31754
> [   84.742187] b43-phy0: Hardware crypto acceleration not supported by firmware
> --

Hard to say, you forgot to tell what is the kernel version.

I guess you didnt upgrade your tree recently ?

# git describe --contains 30e6c9fa93cf3dbc7cc6df1d748ad25e4264545a
v3.8-rc2~19^2~17

^ permalink raw reply

* RE: [PATCH 0/5]: soreuseport: Bind multiple sockets to the same port
From: Eric Dumazet @ 2013-01-17 14:27 UTC (permalink / raw)
  To: David Laight; +Cc: Tom Herbert, netdev, davem, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7112@saturn3.aculab.com>

On Thu, 2013-01-17 at 09:53 +0000, David Laight wrote:
> > We had considered solving this within accept.  The problem is that
> > there's no way to indicate how much work a thread should do via
> > accept.  For instance, an event loop usually would look like:
> > 
> > while (1) {
> >     fd = accept();
> >     process(fd);
> > }
> > 
> > With multiple threads, the number of accepted sockets in a particular
> > thread is non-deterministic...
> 
> If your loop looks like that then each thread is only processing
> a single socket and won't call accept() again until it is idle.
> 
> OTOH if each thread is processing multiple requests using
> poll/select (or similar) at the top of the loop then a single
> thread is likely to pick up a large number of connections.
> 
> Given that both poll and select are inefficient with very large
> numbers of fds (every call is usually o(n) [1]), the kernel will
> support some kind of event mechanism, maybe tweaking that to
> signal the waiters in turn would also work - and be more general.
> 
> It might also be possible to do something on the user side of
> sockets to generate additional fd with their own queue?
> (IMHO some of the SCTP stuff should have been done that way).

I hope you dont really believe Tom was going to explain how
a typical server is built around the accept() thing.

Linux has epoll() mechanism, so the poll()/select() O(n) behavior
are not relevant for modern applications.

^ permalink raw reply

* [PATCH net-next] bnx2x: fix GRO parameters
From: Yuval Mintz @ 2013-01-17 13:26 UTC (permalink / raw)
  To: davem, eric.dumazet, netdev; +Cc: eilong, ariele, Yuval Mintz

bnx2x does an internal GRO pass but doesn't provide gso_segs, thus
breaking qdisc_pkt_len_init() in case ingress qdisc is used.

We store gso_segs in NAPI_GRO_CB(skb)->count, where tcp_gro_complete()
expects to find the number of aggregated segments.

Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
---
This is Eric Dumazet's patch with slight semantic modifications.
Eric - Do you want to put your ack or signoff on this patch?

Dave - Please apply this to 'net-next' afterwards.

Thanks,
Yuval Mintz
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 47 ++++++++++++-------------
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 18fc26e..49810a0 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -439,31 +439,34 @@ static void bnx2x_tpa_start(struct bnx2x_fastpath *fp, u16 queue,
  */
 #define TPA_TSTAMP_OPT_LEN	12
 /**
- * bnx2x_set_lro_mss - calculate the approximate value of the MSS
+ * bnx2x_set_gro_params - compute GRO values
  *
- * @bp:			driver handle
+ * @skb:		packet skb
  * @parsing_flags:	parsing flags from the START CQE
  * @len_on_bd:		total length of the first packet for the
  *			aggregation.
+ * @pkt_len:		length of all segments
  *
  * Approximate value of the MSS for this aggregation calculated using
  * the first packet of it.
+ * Compute number of aggregated segments, and gso_type
  */
-static u16 bnx2x_set_lro_mss(struct bnx2x *bp, u16 parsing_flags,
-			     u16 len_on_bd)
+static void bnx2x_set_gro_params(struct sk_buff *skb, u16 parsing_flags,
+				 u16 len_on_bd, unsigned int pkt_len)
 {
-	/*
-	 * TPA arrgregation won't have either IP options or TCP options
+	/* TPA aggregation won't have either IP options or TCP options
 	 * other than timestamp or IPv6 extension headers.
 	 */
 	u16 hdrs_len = ETH_HLEN + sizeof(struct tcphdr);
 
 	if (GET_FLAG(parsing_flags, PARSING_FLAGS_OVER_ETHERNET_PROTOCOL) ==
-	    PRS_FLAG_OVERETH_IPV6)
+	    PRS_FLAG_OVERETH_IPV6) {
 		hdrs_len += sizeof(struct ipv6hdr);
-	else /* IPv4 */
+		skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
+	} else {
 		hdrs_len += sizeof(struct iphdr);
-
+		skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
+	}
 
 	/* Check if there was a TCP timestamp, if there is it's will
 	 * always be 12 bytes length: nop nop kind length echo val.
@@ -473,7 +476,13 @@ static u16 bnx2x_set_lro_mss(struct bnx2x *bp, u16 parsing_flags,
 	if (parsing_flags & PARSING_FLAGS_TIME_STAMP_EXIST_FLAG)
 		hdrs_len += TPA_TSTAMP_OPT_LEN;
 
-	return len_on_bd - hdrs_len;
+	skb_shinfo(skb)->gso_size = len_on_bd - hdrs_len;
+
+	/* tcp_gro_complete() will copy NAPI_GRO_CB(skb)->count
+	 * to skb_shinfo(skb)->gso_segs
+	 */
+	NAPI_GRO_CB(skb)->count = DIV_ROUND_UP(pkt_len - hdrs_len,
+					       skb_shinfo(skb)->gso_size);
 }
 
 static int bnx2x_alloc_rx_sge(struct bnx2x *bp,
@@ -527,19 +536,9 @@ static int bnx2x_fill_frag_skb(struct bnx2x *bp, struct bnx2x_fastpath *fp,
 	}
 
 	/* This is needed in order to enable forwarding support */
-	if (frag_size) {
-		skb_shinfo(skb)->gso_size = bnx2x_set_lro_mss(bp,
-					tpa_info->parsing_flags, len_on_bd);
-
-		/* set for GRO */
-		if (fp->mode == TPA_MODE_GRO && skb_shinfo(skb)->gso_size)
-			skb_shinfo(skb)->gso_type =
-			    (GET_FLAG(tpa_info->parsing_flags,
-				      PARSING_FLAGS_OVER_ETHERNET_PROTOCOL) ==
-						PRS_FLAG_OVERETH_IPV6) ?
-				SKB_GSO_TCPV6 : SKB_GSO_TCPV4;
-	}
-
+	if (frag_size)
+		bnx2x_set_gro_params(skb, tpa_info->parsing_flags, len_on_bd,
+				     le16_to_cpu(cqe->pkt_len));
 
 #ifdef BNX2X_STOP_ON_ERROR
 	if (pages > min_t(u32, 8, MAX_SKB_FRAGS)*SGE_PAGE_SIZE*PAGES_PER_SGE) {
@@ -651,7 +650,7 @@ static void bnx2x_gro_receive(struct bnx2x *bp, struct bnx2x_fastpath *fp,
 			       struct sk_buff *skb)
 {
 #ifdef CONFIG_INET
-	if (fp->mode == TPA_MODE_GRO && skb_shinfo(skb)->gso_size) {
+	if (skb_shinfo(skb)->gso_size) {
 		skb_set_network_header(skb, 0);
 		switch (be16_to_cpu(skb->protocol)) {
 		case ETH_P_IP:
-- 
1.8.1.227.g44fe835

^ permalink raw reply related

* Re: [PATCH net-next V1 5/6] net/mlx4_en: Fix a race when closing TX queue
From: Eric Dumazet @ 2013-01-17 14:22 UTC (permalink / raw)
  To: Amir Vadai
  Cc: David S. Miller, netdev, Or Gerlitz, Yevgeny Petrilin,
	Eugenia Emantayev
In-Reply-To: <1358423241-2452-6-git-send-email-amirv@mellanox.com>

On Thu, 2013-01-17 at 13:47 +0200, Amir Vadai wrote:
> There is a possible race where the TX completion handler can clean the
> entire TX queue between the decision that the queue is full and actually
> closing it. To avoid this situation, check again if the queue is really
> full, if not, reopen the transmit and continue with sending the packet.
> 
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.com>
> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
>  drivers/net/ethernet/mellanox/mlx4/en_tx.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 2b799f4..1d17f5f 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -592,7 +592,14 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>  		netif_tx_stop_queue(ring->tx_queue);
>  		priv->port_stats.queue_stopped++;
>  
> -		return NETDEV_TX_BUSY;
> +		/* Check again whether the queue was cleaned */
> +		if (unlikely(((int)(ring->prod - ring->cons)) <=
> +				ring->size - HEADROOM - MAX_DESC_TXBBS)) {
> +			netif_tx_wake_queue(ring->tx_queue);
> +			priv->port_stats.wake_queue++;
> +		} else {
> +			return NETDEV_TX_BUSY;
> +		}
>  	}
>  
>  	/* Track current inflight packets for performance analysis */

This looks racy to me. You probably want explicit memory barriers ?

^ permalink raw reply

* Re: [net-next 09/14] igb: Report L4 Rx hash via skb->l4_rxhash
From: Eric Dumazet @ 2013-01-17 14:19 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo, sassmann
In-Reply-To: <1358422519-20981-10-git-send-email-jeffrey.t.kirsher@intel.com>

On Thu, 2013-01-17 at 03:35 -0800, Jeff Kirsher wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> This change makes it so that we report when the Rx hash data is based on L4
> protocol inputs, specifically TCP or UDP port numbers.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>  drivers/net/ethernet/intel/igb/e1000_82575.h |  9 +++++++++
>  drivers/net/ethernet/intel/igb/igb_main.c    | 21 +++++++++++++++++++--
>  2 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.h b/drivers/net/ethernet/intel/igb/e1000_82575.h
> index 444f6f5..fa13e70 100644
> --- a/drivers/net/ethernet/intel/igb/e1000_82575.h
> +++ b/drivers/net/ethernet/intel/igb/e1000_82575.h
> @@ -112,11 +112,20 @@ union e1000_adv_rx_desc {
>  	} wb;  /* writeback */
>  };
>  
> +#define E1000_RXDADV_RSSTYPE_MASK	0x0000000F
>  #define E1000_RXDADV_HDRBUFLEN_MASK      0x7FE0
>  #define E1000_RXDADV_HDRBUFLEN_SHIFT     5
>  #define E1000_RXDADV_STAT_TS             0x10000 /* Pkt was time stamped */
>  #define E1000_RXDADV_STAT_TSIP           0x08000 /* timestamp in packet */
>  
> +/* RSS Hash results */
> +#define E1000_RXDADV_RSSTYPE_IPV4_TCP	0x00000001
> +#define E1000_RXDADV_RSSTYPE_IPV6_TCP	0x00000003
> +#define E1000_RXDADV_RSSTYPE_IPV6_TCP_EX 0x00000006
> +#define E1000_RXDADV_RSSTYPE_IPV4_UDP	0x00000007
> +#define E1000_RXDADV_RSSTYPE_IPV6_UDP	0x00000008
> +#define E1000_RXDADV_RSSTYPE_IPV6_UDP_EX 0x00000009
> +
>  /* Transmit Descriptor - Advanced */
>  union e1000_adv_tx_desc {
>  	struct {
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index a9cb84a..2c66ec8 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -6280,12 +6280,29 @@ static inline void igb_rx_checksum(struct igb_ring *ring,
>  		le32_to_cpu(rx_desc->wb.upper.status_error));
>  }
>  
> +#define IGB_RSS_L4TYPES \
> +	(((u16)1 << E1000_RXDADV_RSSTYPE_IPV4_TCP) | \
> +	 ((u16)1 << E1000_RXDADV_RSSTYPE_IPV4_UDP) | \
> +	 ((u16)1 << E1000_RXDADV_RSSTYPE_IPV6_TCP) | \
> +	 ((u16)1 << E1000_RXDADV_RSSTYPE_IPV6_UDP) | \
> +	 ((u16)1 << E1000_RXDADV_RSSTYPE_IPV6_TCP_EX) | \
> +	 ((u16)1 << E1000_RXDADV_RSSTYPE_IPV6_UDP_EX))
> +
>  static inline void igb_rx_hash(struct igb_ring *ring,
>  			       union e1000_adv_rx_desc *rx_desc,
>  			       struct sk_buff *skb)
>  {
> -	if (ring->netdev->features & NETIF_F_RXHASH)
> -		skb->rxhash = le32_to_cpu(rx_desc->wb.lower.hi_dword.rss);
> +	u16 rss_type;
> +
> +	if (!(ring->netdev->features & NETIF_F_RXHASH))
> +		return;
> +
> +	skb->rxhash = le32_to_cpu(rx_desc->wb.lower.hi_dword.rss);
> +
> +	rss_type = le16_to_cpu(rx_desc->wb.lower.lo_dword.pkt_info) &
> +		   E1000_RXDADV_RSSTYPE_MASK;
> +
> +	skb->l4_rxhash = (IGB_RSS_L4TYPES >> rss_type) & 0x1;
>  }
>  

Problem is that we should not set l4_rxhash for UDP traffic, as it might
contains encapsulated protocol.

Also, is IGB really using the ports in the rss for UDP packets ?

^ permalink raw reply

* Re: [PATCH] ipv6: add anti-spoofing checks for 6to4 and 6rd
From: Hannes Frederic Sowa @ 2013-01-17 13:27 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20130117033258.GA23782@order.stressinduktion.org>

On Thu, Jan 17, 2013 at 04:32:58AM +0100, Hannes Frederic Sowa wrote:
> +static int sit_chksrc(struct ip_tunnel *tunnel, const __be32 *addr,
> +		const struct in6_addr *addr6)
> +{
> +#ifdef CONFIG_IPV6_SIT_6RD
> +	if (ipv6_prefix_equal(addr6, &tunnel->ip6rd.prefix,
> +				tunnel->ip6rd.prefixlen) &&
> +		memcmp(addr, &addr6->s6_addr16[1], 4))
> +		return 0;

This is wrong. David, please drop my patch, sorry. I will respin another one.
In 6rd setups one can, of course, have longer prefixlens than 16.

Thanks!

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox