* Re: [PATCH v2] net/macb: fix sparse warning
From: David Miller @ 2015-02-06 0:06 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <1423153267-1768-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 16:21:07 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
>
> Alongside drops exporting of gem_ethtool_ops as there is no need.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] vxge: fix sparse warning
From: David Miller @ 2015-02-06 0:07 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: jdmason, netdev, linux-kernel
In-Reply-To: <1423144569-28648-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 13:56:09 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> vxge-config.c:4640:30: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* gre interfaces copied to new namespace
From: Steve Biggs @ 2015-02-05 23:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
(My first post to this list. I forgot to change my settings and I sent the previous version of this post using HTML mail. Terribly sorry if this caused anybody any problems; won't happen again... it may be that it never got to the list at all?)
I am going under the assumption that a newly created network namespace should have the loopback (lo) device as its only contents, with it being an error to have any other already existing interfaces in the default namespace also copied in. If this assumption is wrong, please advise and then if so, sorry for the noise.
I was able to reproduce this on a vanilla Debian Wheezy installation with the following sequence of commands. Debian Wheezy is running an older kernel version, so this is a long-standing issue. I am also able to reproduce this on a 3.14.y based kernel.
# ip netns list
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
# modprobe ip_gre
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
12: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
link/gre 0.0.0.0 brd 0.0.0.0
13: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# ip netns add foo
# ip netns list
foo
# ip netns exec foo ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# rmmod ip_gre
# ip netns exec foo ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ip netns del foo
# ip netns list
#
^ permalink raw reply
* Re: Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)
From: Eric Dumazet @ 2015-02-06 0:17 UTC (permalink / raw)
To: Avery Fay; +Cc: netdev, Neal Cardwell
In-Reply-To: <CAO-X30umnbpQG9mwj67ZUkxQpVcGgMMsP8SqY=_3ZeoTczjbmQ@mail.gmail.com>
On Thu, 2015-02-05 at 15:25 -0800, Avery Fay wrote:
> Are these available anywhere? Or could they be made available? This
> seems like a much better solution than disabling timestamps.
Neal is currently polishing a serie of 4 patches.
This should be land to netdev shortly ;)
Thanks
^ permalink raw reply
* Re: [RFC] Possible data stall with RPS and CPU hotplug
From: Eric Dumazet @ 2015-02-06 0:20 UTC (permalink / raw)
To: subashab; +Cc: netdev, therbert
In-Reply-To: <29656169f6b412195cea472d21c89b4f.squirrel@www.codeaurora.org>
On Thu, 2015-02-05 at 23:32 +0000, subashab@codeaurora.org wrote:
> Thanks for the suggestion. It appears to be an oversight on my part that
> the device where the crash was reported did not have commit
> ac64da0b83d82abe62f78b3d0e21cca31aea24fa ("net: rps: fix cpu unplug").
I tried very hard to crash the net-next kernel and I couldn't.
(I got harmless "NOHZ: local_softirq_pending 08" messages only)
But maybe your arch behaves differently in cpu hotplug territory.
^ permalink raw reply
* Re: gre interfaces copied to new namespace
From: Stephen Hemminger @ 2015-02-05 23:51 UTC (permalink / raw)
To: Steve Biggs; +Cc: netdev@vger.kernel.org
In-Reply-To: <EDD8E64855FBDA45ACDFE02112E795B7109CB5DC63@HQ1-EXCH03.corp.brocade.com>
On Thu, 5 Feb 2015 15:37:33 -0800
Steve Biggs <sbiggs@Brocade.com> wrote:
> (My first post to this list. I forgot to change my settings and I sent the previous version of this post using HTML mail. Terribly sorry if this caused anybody any problems; won't happen again... it may be that it never got to the list at all?)
>
> I am going under the assumption that a newly created network namespace should have the loopback (lo) device as its only contents, with it being an error to have any other already existing interfaces in the default namespace also copied in. If this assumption is wrong, please advise and then if so, sorry for the noise.
>
> I was able to reproduce this on a vanilla Debian Wheezy installation with the following sequence of commands. Debian Wheezy is running an older kernel version, so this is a long-standing issue. I am also able to reproduce this on a 3.14.y based kernel.
>
> # ip netns list
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> # modprobe ip_gre
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 12: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
> link/gre 0.0.0.0 brd 0.0.0.0
> 13: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # ip netns add foo
> # ip netns list
> foo
> # ip netns exec foo ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
> link/gre 0.0.0.0 brd 0.0.0.0
> 3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # rmmod ip_gre
> # ip netns exec foo ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> # ip netns del foo
> # ip netns list
> #
>
gre0 and friends are old weird legacy leftovers. They should be copied.
They are the tunnel of last resort for packets that match no defined tunnel.
Nothing should be using them directly.
^ permalink raw reply
* Re: [PATCH net] pktgen: fix UDP checksum computation
From: Eric Dumazet @ 2015-02-06 0:28 UTC (permalink / raw)
To: Tom Herbert; +Cc: Sabrina Dubroca, David Miller, Linux Netdev List, Thomas Graf
In-Reply-To: <CA+mtBx9dT5JkDzj8AYojZBrm5-fd0GN0ZxY47t-43sZoqZmGsg@mail.gmail.com>
On Thu, 2015-02-05 at 15:57 -0800, Tom Herbert wrote:
> Would it be possible to use udp_set_csum to handle all of this?
This reminds me we have following sparse errors with checksum code,
could you take a look Tom ?
make C=2 CF=-D__CHECK_ENDIAN__ ...
include/linux/skbuff.h:3022:24: warning: incorrect type in return expression (different base types)
include/linux/skbuff.h:3022:24: expected restricted __sum16
include/linux/skbuff.h:3022:24: got int
net/ipv6/ip6_checksum.c:83:16: warning: incorrect type in return expression (different base types)
net/ipv6/ip6_checksum.c:83:16: expected int
net/ipv6/ip6_checksum.c:83:16: got restricted __sum16 [assigned] [usertype] __ret
CHECK net/ipv4/tcp_offload.c
net/ipv4/tcp_offload.c:139:60: warning: incorrect type in argument 2 (different base types)
net/ipv4/tcp_offload.c:139:60: expected restricted __wsum [usertype] res
net/ipv4/tcp_offload.c:139:60: got fouled restricted __sum16
include/linux/skbuff.h:3317:14: warning: incorrect type in assignment (different base types)
include/linux/skbuff.h:3317:14: expected unsigned short [unsigned] [usertype] csum
include/linux/skbuff.h:3317:14: got restricted __sum16
include/linux/skbuff.h:3322:16: warning: incorrect type in return expression (different base types)
include/linux/skbuff.h:3322:16: expected restricted __sum16
include/linux/skbuff.h:3322:16: got unsigned short [unsigned] [usertype] csum
net/ipv4/tcp_offload.c:173:52: warning: incorrect type in argument 2 (different base types)
net/ipv4/tcp_offload.c:173:52: expected restricted __wsum [usertype] res
net/ipv4/tcp_offload.c:173:52: got fouled restricted __sum16
include/linux/skbuff.h:3317:14: warning: incorrect type in assignment (different base types)
include/linux/skbuff.h:3317:14: expected unsigned short [unsigned] [usertype] csum
include/linux/skbuff.h:3317:14: got restricted __sum16
include/linux/skbuff.h:3322:16: warning: incorrect type in return expression (different base types)
include/linux/skbuff.h:3322:16: expected restricted __sum16
include/linux/skbuff.h:3322:16: got unsigned short [unsigned] [usertype] csum
^ permalink raw reply
* Re: [RFC PATCH 02/29] net: Flip net_device to use net_ctx
From: David Ahern @ 2015-02-06 0:45 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D37468.6040508@6wind.com>
On 2/5/15 6:47 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> +static inline
>> +int dev_net_ctx_eq(const struct net_device *dev, struct net_ctx *ctx)
>> +{
>> + if (net_eq(dev_net(dev), ctx->net))
>> + return 1;
> Why not using net_ctx_eq()?
right, will change it.
^ permalink raw reply
* Re: [RFC PATCH 14/29] net: vrf: Introduce vrf header file
From: David Ahern @ 2015-02-06 0:52 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D373D0.40405@6wind.com>
On 2/5/15 6:44 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> Defines for min and max vrf id and helpers for examining
>>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>> ---
>> include/net/vrf.h | 36 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 include/net/vrf.h
>>
>> diff --git a/include/net/vrf.h b/include/net/vrf.h
>> new file mode 100644
>> index 000000000000..67bc2e465661
>> --- /dev/null
>> +++ b/include/net/vrf.h
>> @@ -0,0 +1,36 @@
>> +#ifndef _VRF_H_
>> +#define _VRF_H_
>> +
>> +#define VRF_BITS 12
>> +#define VRF_MIN 1
>> +#define VRF_MAX ((1 << VRF_BITS) - 1)
>> +#define VRF_MASK VRF_MAX
>> +
>> +#define VRF_DEFAULT 1
>> +#define VRF_ANY 0xffff
> It could be useful to expose this value to userland.
Maybe. I was thinking VRF_ANY should stay kernel side only and have a
sockopt value of -1 mean VRF_ANY.
David
^ permalink raw reply
* Re: [PATCH net] tcp: don't include Fast Open option in SYN-ACK on pure SYN-data
From: Neal Cardwell @ 2015-02-06 0:58 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Netdev
In-Reply-To: <1423183446-15280-1-git-send-email-ycheng@google.com>
On Thu, Feb 5, 2015 at 7:44 PM, Yuchung Cheng <ycheng@google.com> wrote:
> If a server has enabled Fast Open and it receives a pure SYN-data
> packet (without a Fast Open option), it won't accept the data but it
> incorrectly returns a SYN-ACK with a Fast Open cookie and also
> increments the SNMP stat LINUX_MIB_TCPFASTOPENPASSIVEFAIL.
>
> This patch makes the server include a Fast Open cookie in SYN-ACK
> only if the SYN has some Fast Open option (i.e., when client
> requests or presents a cookie).
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_fastopen.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
neal
^ permalink raw reply
* [PATCH net] amd-xgbe: Check per channel DMA interrupt use in main ISR
From: Tom Lendacky @ 2015-02-06 1:17 UTC (permalink / raw)
To: netdev; +Cc: David Miller
When using per channel DMA interrupts the transmit interrupt (TI) and the
receive interrupt (RI) are masked off so as to not generate an interrupt
to the main ISR. However, should another interrupt fire for the DMA channel
that is handled by the main ISR the TI/RI bits can still be set. This
will cause the wrong and uninitialized napi structure to be used causing a
panic. Add a check to be sure per channel DMA interrupts are not enabled
before acting on those bit flags.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index e5ffb2c..477a7e3 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -337,12 +337,13 @@ static irqreturn_t xgbe_isr(int irq, void *data)
dma_ch_isr = XGMAC_DMA_IOREAD(channel, DMA_CH_SR);
DBGPR(" DMA_CH%u_ISR = %08x\n", i, dma_ch_isr);
- /* If we get a TI or RI interrupt that means per channel DMA
- * interrupts are not enabled, so we use the private data napi
- * structure, not the per channel napi structure
+ /* The TI or RI interrupt bits may still be set even if using
+ * per channel DMA interrupts. Check to be sure those are not
+ * enabled before using the private data napi structure.
*/
- if (XGMAC_GET_BITS(dma_ch_isr, DMA_CH_SR, TI) ||
- XGMAC_GET_BITS(dma_ch_isr, DMA_CH_SR, RI)) {
+ if (!pdata->per_channel_irq &&
+ (XGMAC_GET_BITS(dma_ch_isr, DMA_CH_SR, TI) ||
+ XGMAC_GET_BITS(dma_ch_isr, DMA_CH_SR, RI))) {
if (napi_schedule_prep(&pdata->napi)) {
/* Disable Tx and Rx interrupts */
xgbe_disable_rx_tx_ints(pdata);
^ permalink raw reply related
* Re: [RFC PATCH 18/29] net: vrf: Plumbing for vrf context on a socket
From: David Ahern @ 2015-02-06 1:18 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D373CA.20008@6wind.com>
On 2/5/15 6:44 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> Sockets inherit the vrf context of the task opening it. The context can
>> be read/changed via a socket option (IP_VRF_CONTEXT).
> What about using a common socket option (SO_VRF_CONTEXT) instead of an ipv4
> specific option?
Makes sense.
^ permalink raw reply
* Re: [RFC PATCH 19/29] net: vrf: Add vrf context to skb
From: David Ahern @ 2015-02-06 1:21 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D37414.104@6wind.com>
On 2/5/15 6:45 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> On ingress skb's inherit vrf context from the net_device. For TX skb's
>> inherit the vrf context from the socket originating the packet. Update
>> SKB related net_ctx macros to set vrf.
> Is it really needed to have this skb->vrf?
> Is it not possible to get the vrf from sockets, interfaces, etc? Like
> it's done
> with netns?
One reason is for VRF_ANY context of sockets.
Another one is netlink messages getting funneled through a single kernel
netlink socket; skb->vrf is used to retain vrf handling.
in time might be able to make it go away.
^ permalink raw reply
* Re: [RFC PATCH 25/29] net: vrf: Handle VRF any context
From: David Ahern @ 2015-02-06 1:23 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D3742E.9020607@6wind.com>
On 2/5/15 6:46 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> VRF any context applies only to tasks to and sockets. Devices are
>> associated with a single VRF, and skb's by extension are connected to
>> a single VRF.
>>
>> Listen sockets and unconnected sockets can be opened in a "VRF any"
>> context allowing a single daemon to provide service across all VRFs
>> in a namespace. Connected sockets must be in a specific vrf context.
>> Accepted sockets acquire the VRF context from the device the packet
>> enters (via the skb).
>>
>> "VRF any" context is also useful for tasks wanting to view L3/L4
>> data for all VRFs.
>>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>> ---
> [snip]
>> +static inline int neigh_parms_net_ctx_eq_any(const struct neigh_parms
>> *parms,
>> + const struct net_ctx *net_ctx)
>> +{
>> +#ifdef CONFIG_NET_NS
>> + if (net_eq(neigh_parms_net(parms), net_ctx->net) &&
>> + (vrf_eq(neigh_parms_vrf(parms), net_ctx->vrf) ||
>> + vrf_is_any(net_ctx->vrf))) {
>> + return 1;
>> + }
>> +
>> + return 0;
>> +#else
>> + return 1;
>> +#endif
> If I understand well, the way the patch is done, VRF can be used only if
> CONFIG_NET_NS is enabled.
> But if I'm not wrong, it could be independent. Am I right?
>
Yes. VRF can exist without namespace. It became tedious to keep tracking
the CONFIG_NET_NS for the RFC set. Would certainly do that for later
versions.
^ permalink raw reply
* Re: [PATCH] ixgbe: fix sparse warnings
From: Jeff Kirsher @ 2015-02-06 1:30 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Matthew Vick, John Ronciak, Mitch Williams, Linux NICS,
e1000-devel, netdev, linux-kernel
In-Reply-To: <1423146452-9379-1-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]
On Thu, 2015-02-05 at 14:27 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> ixgbe_x550.c:83:5: warning: symbol 'ixgbe_init_eeprom_params_X550' was
> not declared. Should it be static?
> ixgbe_x550.c:113:5: warning: symbol 'ixgbe_read_iosf_sb_reg_x550' was
> not declared. Should it be static?
> ixgbe_x550.c:161:5: warning: symbol 'ixgbe_read_ee_hostif_data_X550'
> was not declared. Should it be static?
> ixgbe_x550.c:196:5: warning: symbol 'ixgbe_read_ee_hostif_buffer_X550'
> was not declared. Should it be static?
> ixgbe_x550.c:334:5: warning: symbol 'ixgbe_calc_checksum_X550' was not
> declared. Should it be static?
> ixgbe_x550.c:410:5: warning: symbol 'ixgbe_calc_eeprom_checksum_X550'
> was not declared. Should it be static?
> ixgbe_x550.c:422:5: warning: symbol 'ixgbe_read_ee_hostif_X550' was
> not declared. Should it be static?
> ixgbe_x550.c:443:5: warning: symbol
> 'ixgbe_validate_eeprom_checksum_X550' was not declared. Should it be
> static?
> ixgbe_x550.c:492:5: warning: symbol 'ixgbe_write_ee_hostif_data_X550'
> was not declared. Should it be static?
> ixgbe_x550.c:520:5: warning: symbol 'ixgbe_write_ee_hostif_X550' was
> not declared. Should it be static?
> ixgbe_x550.c:540:5: warning: symbol 'ixgbe_update_flash_X550' was not
> declared. Should it be static?
> ixgbe_x550.c:563:5: warning: symbol
> 'ixgbe_update_eeprom_checksum_X550' was not declared. Should it be
> static?
> ixgbe_x550.c:603:5: warning: symbol
> 'ixgbe_write_ee_hostif_buffer_X550' was not declared. Should it be
> static?
> ixgbe_x550.c:633:6: warning: symbol 'ixgbe_init_mac_link_ops_X550em'
> was not declared. Should it be static?
> ixgbe_x550.c:650:5: warning: symbol 'ixgbe_setup_sfp_modules_X550em'
> was not declared. Should it be static?
> ixgbe_x550.c:706:5: warning: symbol
> 'ixgbe_get_link_capabilities_X550em' was not declared. Should it be
> static?
> ixgbe_x550.c:743:5: warning: symbol 'ixgbe_write_iosf_sb_reg_x550' was
> not declared. Should it be static?
> ixgbe_x550.c:907:5: warning: symbol 'ixgbe_setup_kx4_x550em' was not
> declared. Should it be static?
> ixgbe_x550.c:945:5: warning: symbol 'ixgbe_setup_kr_x550em' was not
> declared. Should it be static?
> ixgbe_x550.c:990:5: warning: symbol 'ixgbe_setup_internal_phy_x550em'
> was not declared. Should it be static?
> ixgbe_x550.c:1052:5: warning: symbol 'ixgbe_init_phy_ops_X550em' was
> not declared. Should it be static?
> ixgbe_x550.c:1105:23: warning: symbol 'ixgbe_get_media_type_X550em'
> was not declared. Should it be static?
> ixgbe_x550.c:1132:5: warning: symbol 'ixgbe_init_ext_t_x550em' was not
> declared. Should it be static?
> ixgbe_x550.c:1205:5: warning: symbol 'ixgbe_reset_hw_X550em' was not
> declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Found this issue on linux-next (gcc version 4.9.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 64
> ++++++++++++++-------------
> 1 file changed, 34 insertions(+), 30 deletions(-)
Don Skidmore already has a patch to resolve these warnings in my queue.
So I will be dropping this patch.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: David Ahern @ 2015-02-06 1:32 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: ebiederm
In-Reply-To: <54D373B4.3050603@6wind.com>
On 2/5/15 6:44 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
> [snip]
>> This is accomplished by enhancing the current namespace checks to a
>> broader network context that is both a namepsace and a VRF id. The VRF
>> id is a tag applied to relevant structures, an integer between 1 and 4095
>> which allows for 4095 VRFs (could have 0 be the default VRF and then the
>> range is 0-4095 = 4096s VRFs). (The limitation is arguably artificial. It
>> is based on the genid scheme for versioning networking data which is a
>> 32-bit integer. The VRF id is the lower 12 bits of the genid's.)
> Would it be possible to avoid this artificial limit?
> There could be scenarii with more than 4096 vrf.
As I recall the genid was the only reason to put a limit on it. I know
of one product with a higher limit (16k I believe), but I figured this
was a reasonable start point for the discussion.
>
> Do you plan to have a way to dump or monitor VRF via netlink?
What do you mean? There is no creation / deletion event. Are you
referring to monitoring device changes -- device moved from one network
context (namespace, vrf) to another?
The VRF id can be added as an attribute to all relevant netlink
notifications.
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: Stephen Hemminger @ 2015-02-06 1:33 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, ebiederm
In-Reply-To: <1423100070-31848-1-git-send-email-dsahern@gmail.com>
On Wed, 4 Feb 2015 18:34:01 -0700
David Ahern <dsahern@gmail.com> wrote:
> Kernel patches are also available here:
> https://github.com/dsahern/linux.git vrf-3.19
>
> iproute2 patches are also available here:
> https://github.com/dsahern/iproute2 vrf-3.19
>
>
> Background
> ----------
> The concept of VRFs (Virtual Routing and Forwarding) has been around for over
> 15 years. Support for VRFs in the Linux kernel has been an often requested
> feature for almost as long. For a while support was available via an out of
> tree patch [1]. Since network namespaces came along, the response to queries
> about VRF support for Linux was 'use namespaces'. But as mentioned previously
> [2] network namespaces are not a good match for VRFs. Of the list of problems
> noted the big one is that namespaces do not scale efficiently to the number
> of VRFs supported by networking gear (> 1000 VRFs). Networking vendors that
> want to use Linux as the OS have to carry custom solutions to this problem --
> be it userspace networking stacks, extensive kernel patches (to add VRF
> support or bend the implementation of namespaces), and/or patches to many
> open source components. The recent addition of switchdev support in the
> kernel suggests that people expect the use of Linux as a switch networking
> OS to increase. Hopefully the time is right to re-open the discussion on a
> salable VRF implementation for the Linux kernel.
>
> The intent of this RFC is to get feedback on the overall idea - namely VRFs
> as integer id and the nesting of VRFs within a namespace. This set includes
> changes only to core IPv4 code which shows the concept; changes to the rest
> of the network stack are fairly repetitive.
>
> This patch set has a number of similarities to the original VRF patch - most
> notably VRF ids as an integer index and plumbing through iproute2 and
> netlink. But this set is really a complete re-implementation of the feature,
> integrating VRF within a namespace and leveraging existing support for
> network namespaces.
>
> Design
> ------
> Namespaces provide excellent separation of the networking stack from the
> netdevices and up. The intent of VRFs is to provide an additional,
> logical separation at the L3 layer within a namespace.
>
> +----------------------------------------------------------+
> | Namespace foo |
> | +---------------+ |
> | +------+ | L3/L4 service | |
> | | lldp | | (VRF any) | |
> | +------+ +---------------+ |
> | |
> | +-------------------------+ |
> | | VRF M | |
> | +---------------------+ +-------------------------+ | |
> | | VRF 1 (default) | | VRF N | | |
> | | +---------------+ | | +---------------+ | | |
> | | | L3/L4 service | | | | L3/L4 service | | | |
> | | | (VRF unaware) | | | | (VRF unaware) | | | |
> | | +---------------+ | | +---------------+ | | |
> | | | | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | || FIB | | neighbor | | | | FIB | | neighbor | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | | | | |-+ |
> | | {dev 1} {dev 2} | | {dev 3} {dev 4} {dev 5} | |
> | +---------------------+ +-------------------------+ |
> +----------------------------------------------------------+
>
> This is accomplished by enhancing the current namespace checks to a
> broader network context that is both a namepsace and a VRF id. The VRF
> id is a tag applied to relevant structures, an integer between 1 and 4095
> which allows for 4095 VRFs (could have 0 be the default VRF and then the
> range is 0-4095 = 4096s VRFs). (The limitation is arguably artificial. It
> is based on the genid scheme for versioning networking data which is a
> 32-bit integer. The VRF id is the lower 12 bits of the genid's.)
>
> Netdevices, sk_buffs, sockets, and tasks are all tagged with a VRF id.
> Network lookups (devices, sockets, addresses, routes, neighbors) require a
> match of both network namespace and VRF id (or the special 'vrf any' tag;
> more on that later).
>
> Beyond the 4-byte tag in various data structures, there are no resources
> allocated to a VRF so there is no need to create or destroy a VRF which is
> in-line with the concept of keeping it lightweight for scalability. The
> trade-off is that VRFs use the the same sysctl settings as the namespace
> they are part of and, for example, MIB counters.
>
> The VRF id of tasks defaults to 1 and is inherited parent to child. It can
> be read via the file '/proc/<pid>/vrf' and can be changed anytime by writing
> to this file (if preferred this can be made a prctl to change the VRF id).
> This allows services to be launched in a VRF context using ip, similar to
> what is done for network namespaces.
> e.g., ip vrf exec 99 /usr/sbin/sshd
>
> (or a simpler chvrf alias/command can be used to just write the VRF id
> to the proc file.)
>
> The task's VRF id also affects viewing and modifying network configuration.
> For example, 'ip addr show', 'ip route ls', 'ifconfig', 'arp -n', etc, only
> show network data for the VRF associated with the task's VRF id; devices
> are at the L2 layer so a command listing devices is not impacted by VRF id.
>
> When a socket is created the VRF id is taken from the task. Socket-vrf
> association for non-connected sockets can be changed using a setsockopt
> (e.g., create a socket then change VRF id prior to calling bind or connect).
>
> Network devices belong to a single VRF context which defaults to VRF 1.
> They can be assigned to another VRF using IFLA_VRF attribute in link
> messages. Similarly the VRF assignment is returned in the IFLA_VRF
> attribute. The ip command has been modified to display the VRF id of a
> device. L2 applications like lldp are not VRF aware and still work through
> through all network devices within the namespace.
>
> On RX skbs get their VRF context from the netdevice the packet is received
> on. For TX the VRF context for an skb is taken from the socket. The
> intention is for L3/raw sockets to be able to set the VRF context for a
> packet TX using cmsg (not coded in this patch set).
>
> VRF aware apps (e.g., L3 VPNs) can have sockets in multiple VRFs for
> forwarding packets.
>
> The special 'ANY VRF' context allows a single instance of a daemon to
> provide a service across all VRFs.
> e.g., ip vrf exec any /usr/sbin/sshd
>
> The 'any' context applies to listen sockets only; connected sockets are in
> a VRF context. Child sockets accepted by the daemon acquire the VRF context
> of the network device the connection originated on.
>
> The 'ANY VRF' context can also be used to display all addresses, routes
> or neighbors in the kernel cache. That is, 'ip addr show', 'ip route ls',
> 'ifconfig', 'arp -n', etc, show all network data for the namespace.
>
>
> About this Patch Set
> --------------------
> This is not a complete conversion of the networking stack, only a small
> sampling to test the waters. Only changes are to core IPv4 code [2] which
> is sufficient to illustrate the fundamental concept. Changes from
> struct net to net_ctx are very repetitive.
>
> I'm sure there are a lot of oversights and bugs, but the intent here is
> to solicit feedback on the overall idea.
>
>
> Examples
> --------
> To illustrate the VRF patches consider a system with 18 NICs:
> - eth0, eth17 are in default namespace (e.g., management namespace)
>
> - eth1 - eth8 are in group1 namespace
> - eth1 - eth4 are in VRF 11
> - eth5 - eth8 are in VRF 13
>
> - eth9 - eth16 are in group2 namespace
> - eth9 - eth12 are in VRF 21
> - eth13 - eth16 are in VRF 23
>
> - Addresses assigned to each interface:
> - eth1: 1.1.1.1/24
> - eth2: 2.2.2.1/24
> - eth3: 3.3.3.1/24
> - eth4: 4.4.4.1/24
> - eth5: 1.1.1.1/24 (not a typo, duplicate address in different vrfs)
> - eth6: 6.6.6.1/24
> - eth7: 7.7.7.1/24
> - eth8: 8.8.8.1/24
>
> - openlldpd is started in each namespace
>
> 1. device list is VRF agnostic
> - ifconfig -a, ip link show, /proc/net/dev
> --> default namespace shows only eth0 and eth17
> --> group1 namespace shows only eth1 - eth8
> --> group2 namespace shows only eth9 - eth16
> - ip shows vrf assignment of each link
>
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 vrf 11 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
> link/ether 02:ab:cd:02:00:01 brd ff:ff:ff:ff:ff:ff
>
> 2. address, route, neighbor list is VRF aware
> - ifconfig, ip addr show, ip route ls, /proc/net/route
> --> shows only addresses for VRF id of task unless id is 'any'
>
> in VRF 1:
> ifconfig eth1
> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> ether 02:ab:cd:02:00:01 txqueuelen 1000 (Ethernet)
> ...
>
> No addresses are shown. But if the command is run in VRF 11 or VRF 'any'
> ip vrf exec 11 ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 vrf 11 qdisc pfifo_fast state UP group default qlen 1000
> link/ether 02:ab:cd:02:00:01 brd ff:ff:ff:ff:ff:ff
> inet 1.1.1.1/24 brd 1.1.1.255 scope global eth1
> valid_lft forever preferred_lft forever
>
> 3. start ssh in group1 namespace
> ip netns exec group1 ip vrf exec 11 /usr/sbin/sshd -d
> ssh to 1.1.1.1 via eth1
>
> ip netns exec group1 ip vrf exec 13 /usr/sbin/sshd -d
> ssh to 1.1.1.1 via eth5
> --> same namespace but different VRFs
>
> 4. One ssh instance handles VRFs in group1 namespace
> ip netns exec group1 ip vrf exec any /usr/sbin/sshd
>
> --> ssh to any address in the namespace works
>
> References
> ----------
> [1] http://sourceforge.net/projects/linux-vrf
>
> [2] http://www.spinics.net/lists/netdev/msg298368.html
>
> [3] To build only enable core ipv4 code. Disable IPv6, netfilter, ipsec, etc.
It is still not clear how adding another level of abstraction
solves the scaling problem. Is it just because you can have one application
connect to multiple VRF's? so you don't need N routing daemons?
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Scott Feldman @ 2015-02-06 1:45 UTC (permalink / raw)
To: B Viswanath
Cc: Siva Mannem, David Miller, Roopa Prabhu, Netdev,
Jiří Pírko
In-Reply-To: <CAN+pFwKAWX+En6zK3Q94q9ejdpqz6WBvnkH=Rp3HBEAeOyNbNw@mail.gmail.com>
On Thu, Feb 5, 2015 at 10:31 AM, B Viswanath <marichika4@gmail.com> wrote:
> On 5 February 2015 at 23:25, Scott Feldman <sfeldma@gmail.com> wrote:
> <snip>
>>
>> CONs
>>
>> 1) Scale-ability. The bridge driver can't keep up with ageing many
>> (10^5, for example) entries.
>> 2) Scale-ability. Keeping the entries periodically refreshed requires
>> a refresh sync from
>> the device to the bridge driver, and the bridge driver/kernel can't keep up.
>> 3) With the bridge driver, the ageing settings are per-bridge, not per-port.
>>
>> Did I miss any points?
>
> There is one more
>
> 4. On links with wirespeed traffic, software ageing FDB entries
> independently without having the knowledge of the traffic means that
> CPU will ageout entries it should not. I don't know if this breaks
> some RFC, but it can certainly cause big packet loss.
SW would only age out expired entries. An entry not refreshed by HW
will expire. But HW will refresh (to SW) active entries based on
traffic seen. So I'm not seeing how SW will age out entries
prematurely. I'm missing something.
Is there a race perhaps? Maybe that's your point. I think I see the
race. SW has decided entry is expired and sends signal to remove
entry, while in the meantime HW got a hit on entry and wants to
refresh it. So this would cause a service disruption if the entry was
removed and then re-added. But this is a boundary condition on the
hairy edge of the ageing timeout window. Does it matter in practice?
I really want to understand your case 4, but I'm not getting
something. Is there another way to explain it, by example perhaps?
> Such a packet loss is considered bad, and is a primary reason why
> hardware supports ageing. Otherwise there is no reason hw needs to
> support it. Based on experience, I can say that it is a necessity, now
> even more with 10G and 40G links.
^ permalink raw reply
* Re: [PATCH] i40e: fix sparse warning
From: Jeff Kirsher @ 2015-02-06 1:52 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Matthew Vick, John Ronciak, Mitch Williams, Linux NICS,
e1000-devel, netdev, linux-kernel
In-Reply-To: <1423149195-32142-1-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
On Thu, 2015-02-05 at 15:13 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> i40e_lan_hmc.c:911:24: warning: constant 0xFFFFFFFFFFFFFFFF is so big
> it is unsigned long
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Found this issue on linux-next (gcc version 4.8.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I already have a fix in my queue to resolve this issue, so I am dropping
your patch.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: David Ahern @ 2015-02-06 2:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, ebiederm
In-Reply-To: <20150205173334.08248382@uryu.home.lan>
On 2/5/15 6:33 PM, Stephen Hemminger wrote:
> It is still not clear how adding another level of abstraction
> solves the scaling problem. Is it just because you can have one application
> connect to multiple VRF's? so you don't need N routing daemons?
>
>
How do you provide a service in N VRFs? "Service" can be a daemon with a
listen socket (e.g., bgpd, sshd) or a monitoring app (e.g., collectd,
snmpd). For the current namespace only paradigm the options are:
1. replicate the process for each namespace (e.g., N instances of sshd,
bgpd, collectd, snmpd, etc.)
2. a single process spawns a thread for each namespace
3. a single process opens a socket in each namespace
All of those options are rather heavyweight and the number of 'things'
is linear with the number of VRFs. When multiplied by the number of
services needed for a full-featured product the end result is a lot of
wasted resources.
The idea here is to simplify things by allowing a single process to have
a presence / provide a service in all VRFs within a namespace without
the need to spawn a thread, socket or another process.
For example, 1 instance of a monitoring app can still see all of the
netdevices in the namespace and in the VRF_ANY context can still report
network configuration data. VRF unaware/agnostic L3/L4 apps (e.g., sshd)
do not need to be modified and will be able to provide service through
any interface. VRF aware apps (e.g., bgpd) might require modifications
per the implementation of the VRF construct but they would able to
provide service with a single instance.
Nesting VRFs within namespaces provides 2 synergistic constructs for
building separation within a switch -- namespaces at the device layer
(e.g., multiple virtual switches from a single physical switch) with
VRFs at the L3 layer.
David
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: David Ahern @ 2015-02-06 2:19 UTC (permalink / raw)
To: roopa; +Cc: netdev, ebiederm, Dinesh Dutt, Vipin Kumar, Nicolas Dichtel,
hannes
In-Reply-To: <54D3F8F9.2060500@cumulusnetworks.com>
On 2/5/15 4:12 PM, roopa wrote:
> Wondering if you have thought about some of the the below cases in your
> approach to vrfs ?.
> - Leaking routes from one vrf to another
Can you give me an example of what you mean by this?
> - route lookup in one vrf on failure to fallback to the global vrf (This
> for example can be done using throw if we used ip rules and route tables
> to do the same).
> - A route in one vrf pointing to a nexthop in another vrf
I have been more focused on the initial VRF infrastructure and have not
spent too much time on these use cases or other route lookup features
(e.g., allow an application to handle route lookup misses similar to arp
misses, allow custom route lookup modules) that are needed to approach
the feature richness provided by high end routers.
David
^ permalink raw reply
* Re: [PATCH 0/6 v2 net-next] rhashtable fixes
From: Ying Xue @ 2015-02-06 2:36 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, herbert
In-Reply-To: <20150205101954.GA24388@casper.infradead.org>
On 02/05/2015 06:19 PM, Thomas Graf wrote:
> On 02/05/15 at 05:14pm, Ying Xue wrote:
>> On 02/05/2015 04:47 PM, Thomas Graf wrote:
>>> On 02/05/15 at 10:32am, Ying Xue wrote:
>>>> After I applied the sires, it sounds like panic doesn't occur any more. But soft
>>>> lockup still happens although the frequency of its reproduction is much lower
>>>> than before. Please take a look at its relevant log:
>>>
>>> Thanks for testing and the report. I had run your bind_netlink test
>>> overnight on a 4 CPU VM. Anything particular that might help trigger it?
>
> Thanks. I will keep trying to reproduce. Can you try the following
> patch in the meantime?
>
After I applied the below change on the latest net-next tree with the series
patches, panic happens during kernel boot stage as follows:
[ 0.720502] smpboot: Total of 8 processors activated (54278.37 BogoMIPS)
[ 0.728325] devtmpfs: initialized
[ 0.729961] evm: security.selinux
[ 0.730308] evm: security.SMACK64
[ 0.730600] evm: security.capability
[ 0.732507] RTC time: 2:26:37, date: 02/06/15
[ 0.733240] NET: Registered protocol family 16
[ 0.733729] BUG: unable to handle kernel paging request at ffff880042724fb0
[ 0.734371] IP: [<ffffffff8139dd82>] __rhashtable_insert+0x22/0xb0
[ 0.734936] PGD 2c50067 PUD 0
[ 0.735254] Oops: 0000 [#1] SMP
[ 0.735578] Modules linked in:
[ 0.735870] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6+ #186
[ 0.736000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 0.736000] task: ffff880016db8000 ti: ffff880016db4000 task.ti: ffff880016db4000
[ 0.736000] RIP: 0010:[<ffffffff8139dd82>] [<ffffffff8139dd82>]
__rhashtable_insert+0x22/0xb0
[ 0.736000] RSP: 0000:ffff880016db7b78 EFLAGS: 00010286
[ 0.736000] RAX: 0000000000000000 RBX: ffff880016500000 RCX: 000000000574ff73
[ 0.736000] RDX: ffff880016ca5400 RSI: ffff88001651be08 RDI: ffff880016500000
[ 0.736000] RBP: ffff880016db7bb8 R08: 0000000000000000 R09: 0000000000000001
[ 0.736000] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880016ca5400
[ 0.736000] R13: ffff880016ca5400 R14: 000000000574ff73 R15: ffff880016ca5400
[ 0.736000] FS: 0000000000000000(0000) GS:ffff880017c00000(0000)
knlGS:0000000000000000
[ 0.736000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.736000] CR2: ffff880042724fb0 CR3: 0000000001c11000 CR4: 00000000000006f0
[ 0.736000] Stack:
[ 0.736000] 0574ff7300000000 ffff880016ca5400 ffff880016db7bb8 ffff880016500000
[ 0.736000] ffff88001651be08 ffff880016ca5400 000000000574ff73 ffff880016ca5400
[ 0.736000] ffff880016db7c18 ffffffff8139e841 ffffffff8139e775 ffff88001651b800
[ 0.736000] Call Trace:
[ 0.736000] [<ffffffff8139e841>] rhashtable_lookup_compare_insert+0x101/0x110
[ 0.736000] [<ffffffff8139e775>] ? rhashtable_lookup_compare_insert+0x35/0x110
[ 0.736000] [<ffffffff8165d800>] ? jhash+0xe0/0x160
[ 0.736000] [<ffffffff8165e1b3>] ? netlink_insert+0x43/0xf0
[ 0.736000] [<ffffffff8165e201>] netlink_insert+0x91/0xf0
[ 0.736000] [<ffffffff81660a31>] __netlink_kernel_create+0x121/0x260
[ 0.736000] [<ffffffff816288cf>] ? register_pernet_subsys+0x1f/0x50
[ 0.736000] [<ffffffff8164136d>] rtnetlink_net_init+0x4d/0x70
[ 0.736000] [<ffffffff81641fe0>] ? rtnl_unlock+0x10/0x10
[ 0.736000] [<ffffffff8162848e>] ops_init+0x4e/0x150
[ 0.736000] [<ffffffff810a6afd>] ? trace_hardirqs_on+0xd/0x10
[ 0.736000] [<ffffffff81628793>] register_pernet_operations+0xf3/0x190
[ 0.736000] [<ffffffff810a6afd>] ? trace_hardirqs_on+0xd/0x10
[ 0.736000] [<ffffffff816288de>] register_pernet_subsys+0x2e/0x50
[ 0.736000] [<ffffffff81d89e03>] rtnetlink_init+0x10/0x16b
[ 0.736000] [<ffffffff81d8b0bf>] netlink_proto_init+0x194/0x1af
[ 0.736000] [<ffffffff8165d720>] ? __tcf_em_tree_match+0x160/0x160
[ 0.736000] [<ffffffff8139d380>] ? percpu_ida_alloc+0x3c0/0x3c0
[ 0.736000] [<ffffffff8139d3b0>] ? rht_grow_above_75+0x30/0x30
[ 0.736000] [<ffffffff81d8af2b>] ? tc_action_init+0x55/0x55
[ 0.736000] [<ffffffff810002d9>] do_one_initcall+0x89/0x1c0
[ 0.736000] [<ffffffff81d361a1>] kernel_init_freeable+0x1a3/0x23d
[ 0.736000] [<ffffffff81d358f2>] ? do_early_param+0x86/0x86
[ 0.736000] [<ffffffff8174fa10>] ? rest_init+0xd0/0xd0
[ 0.736000] [<ffffffff8174fa1e>] kernel_init+0xe/0xf0
[ 0.736000] [<ffffffff81766eec>] ret_from_fork+0x7c/0xb0
[ 0.736000] [<ffffffff8174fa10>] ? rest_init+0xd0/0xd0
[ 0.736000] Code: 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 40 4c 89 75
f0 41 89 ce 48 89 5d d8 4c 89 65 e0 4c 89 6d e8 49 89 d4 4c 89 7d f8 <4a> 8b 54
f2 18 48 89 fb 49 89 f5 4c 89 e7 89 ce 41 89 cf 48 89
[ 0.736000] RIP [<ffffffff8139dd82>] __rhashtable_insert+0x22/0xb0
[ 0.736000] RSP <ffff880016db7b78>
[ 0.736000] CR2: ffff880042724fb0
[ 0.736000] ---[ end trace 0747bcdb7a563e55 ]---
[ 0.736000] Kernel panic - not syncing: Fatal exception in interrupt
[ 0.736000] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Regards,
Ying
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 5919d63..1c65be2 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -593,7 +593,7 @@ void rhashtable_insert(struct rhashtable *ht, struct rhash_head *obj)
>
> tbl = rht_dereference_rcu(ht->future_tbl, ht);
> old_tbl = rht_dereference_rcu(ht->tbl, ht);
> - hash = head_hashfn(ht, tbl, obj);
> + hash = obj_raw_hashfn(ht, rht_obj(ht, obj));
>
> lock_buckets(tbl, old_tbl, hash);
> __rhashtable_insert(ht, obj, tbl, hash);
> @@ -835,7 +835,7 @@ bool rhashtable_lookup_compare_insert(struct rhashtable *ht,
> rcu_read_lock();
> old_tbl = rht_dereference_rcu(ht->tbl, ht);
> new_tbl = rht_dereference_rcu(ht->future_tbl, ht);
> - new_hash = head_hashfn(ht, new_tbl, obj);
> + new_hash = obj_raw_hashfn(ht, rht_obj(ht, obj));
>
> lock_buckets(new_tbl, old_tbl, new_hash);
>
>
>
>
^ permalink raw reply
* Re: [PATCH v3] net: openvswitch: Support masked set actions.
From: Jesse Gross @ 2015-02-06 3:21 UTC (permalink / raw)
To: Jarno Rajahalme; +Cc: netdev, dev@openvswitch.org
In-Reply-To: <1423172449-3654-1-git-send-email-jrajahalme@nicira.com>
On Thu, Feb 5, 2015 at 1:40 PM, Jarno Rajahalme <jrajahalme@nicira.com> wrote:
> OVS userspace already probes the openvswitch kernel module for
> OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module
> implementation of masked set actions.
>
> The existing set action sets many fields at once. When only a subset
> of the IP header fields, for example, should be modified, all the IP
> fields need to be exact matched so that the other field values can be
> copied to the set action. A masked set action allows modification of
> an arbitrary subset of the supported header bits without requiring the
> rest to be matched.
>
> Masked set action is now supported for all writeable key types, except
> for the tunnel key. The set tunnel action is an exception as any
> input tunnel info is cleared before action processing starts, so there
> is no tunnel info to mask.
>
> The kernel module converts all (non-tunnel) set actions to masked set
> actions. This makes action processing more uniform, and results in
> less branching and duplicating the action processing code. When
> returning actions to userspace, the fully masked set actions are
> converted back to normal set actions. We use a kernel internal action
> code to be able to tell the userspace provided and converted masked
> set actions apart.
>
> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
> ---
> v3: Clean up code and remove flow key transport port checks from
> validate_set(), as suggested by Jesse Gross.
Looks good to me now.
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Siva Mannem @ 2015-02-06 3:27 UTC (permalink / raw)
To: Scott Feldman
Cc: B Viswanath, David Miller, Roopa Prabhu, Netdev,
Jiří Pírko
In-Reply-To: <CAE4R7bDypUjrSAned55XRpcp+iEHNkF7H_8JJy63jt+5Hd3Pzg@mail.gmail.com>
On Fri, Feb 6, 2015 at 7:15 AM, Scott Feldman <sfeldma@gmail.com> wrote:
> On Thu, Feb 5, 2015 at 10:31 AM, B Viswanath <marichika4@gmail.com> wrote:
>> On 5 February 2015 at 23:25, Scott Feldman <sfeldma@gmail.com> wrote:
>> <snip>
>>>
>>> CONs
>>>
>>> 1) Scale-ability. The bridge driver can't keep up with ageing many
>>> (10^5, for example) entries.
>>> 2) Scale-ability. Keeping the entries periodically refreshed requires
>>> a refresh sync from
>>> the device to the bridge driver, and the bridge driver/kernel can't keep up.
>>> 3) With the bridge driver, the ageing settings are per-bridge, not per-port.
>>>
>>> Did I miss any points?
>>
>> There is one more
>>
>> 4. On links with wirespeed traffic, software ageing FDB entries
>> independently without having the knowledge of the traffic means that
>> CPU will ageout entries it should not. I don't know if this breaks
>> some RFC, but it can certainly cause big packet loss.
>
> SW would only age out expired entries. An entry not refreshed by HW
> will expire. But HW will refresh (to SW) active entries based on
> traffic seen. So I'm not seeing how SW will age out entries
> prematurely. I'm missing something.
Hardware does not refresh(to SW) active entries based on the traffic
seen, at least on the switches that I worked on. Even if it were to
refresh, if the traffic is flowing at line rate(say x packets per
sec), the refresh rate to SW is equal to x, which is very huge for cpu
to handle.
There are only two notifications to SW.
1)learn notification(when packet arrives that has smac which is not in
hardware's FDB)
2)When the hardware ages the entry, it sends a age notification.
>
> Is there a race perhaps? Maybe that's your point. I think I see the
> race. SW has decided entry is expired and sends signal to remove
> entry, while in the meantime HW got a hit on entry and wants to
> refresh it. So this would cause a service disruption if the entry was
> removed and then re-added. But this is a boundary condition on the
> hairy edge of the ageing timeout window. Does it matter in practice?
>
> I really want to understand your case 4, but I'm not getting
> something. Is there another way to explain it, by example perhaps?
>
>> Such a packet loss is considered bad, and is a primary reason why
>> hardware supports ageing. Otherwise there is no reason hw needs to
>> support it. Based on experience, I can say that it is a necessity, now
>> even more with 10G and 40G links.
--
Regards,
Siva Mannem.
^ permalink raw reply
* [PATCH net-next v2 0/7] r8152: adjust the code
From: Hayes Wang @ 2015-02-06 3:30 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-118-Taiwan-albertk@realtek.com>
V2:
Correct the subject of patch #5. Replace "link feed" with "line feed".
v1:
Code adjustment.
Hayes Wang (7):
r8152: adjust rx_bottom
r8152: adjust lpm timer
r8152: check linking status with netif_carrier_ok
r8152: check RTL8152_UNPLUG for rtl8152_close
r8152: adjust the line feed for hw_features
r8152: replace get_protocol with vlan_get_protocol
r8152: use BIT macro
drivers/net/usb/r8152.c | 99 +++++++++++++++++++++++--------------------------
1 file changed, 46 insertions(+), 53 deletions(-)
--
2.1.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox