* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:04 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 21:42 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 21:35 UTC (permalink / raw)
I,Birgit authenticate this email, you can read about me on:
http://en.wikipedia.org/wiki/Birgit_Rausing
I have funds for you to manage and disburse to various charities of your
choice. If you are sure you can handle this, it will be of help to you and
others. Please reply if you are interested for more details.please
Contact my private email;( mrs_BirgitRausin0@qq.com ) for more
information
With love,
Mrs Birgit Rausing
^ permalink raw reply
* Re: [PATCH net-next 8/8] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE
From: Jerry Chu @ 2014-10-30 21:20 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev@vger.kernel.org, Matan Barak, Amir Vadai,
Saeed Mahameed, Shani Michaeli
In-Reply-To: <1414685216-28907-9-git-send-email-ogerlitz@mellanox.com>
On Thu, Oct 30, 2014 at 9:06 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> From: Shani Michaeli <shanim@mellanox.com>
>
> When processing received traffic, pass CHECKSUM_COMPLETE status to the
> stack, with calculated checksum for non TCP/UDP packets (such
> as GRE or ICMP).
>
> Although the stack expects checksum which doesn't include the pseudo
> header, the HW adds it. To address that, we are subtracting the pseudo
> header checksum from the checksum value provided by the HW.
>
> In the IPv6 case, we also compute/add the IP header checksum which
> is not added by the HW for such packets.
>
> Cc: Jerry Chu <hkchu@google.com>
> Signed-off-by: Shani Michaeli <shanim@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 +
> drivers/net/ethernet/mellanox/mlx4/en_port.c | 2 +
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 116 +++++++++++++++++++++-
> drivers/net/ethernet/mellanox/mlx4/main.c | 9 ++
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 5 +-
> include/linux/mlx4/device.h | 1 +
> 7 files changed, 132 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> index 8ea4d5b..6c64323 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> @@ -115,7 +115,7 @@ static const char main_strings[][ETH_GSTRING_LEN] = {
> "tso_packets",
> "xmit_more",
> "queue_stopped", "wake_queue", "tx_timeout", "rx_alloc_failed",
> - "rx_csum_good", "rx_csum_none", "tx_chksum_offload",
> + "rx_csum_good", "rx_csum_none", "rx_csum_complete", "tx_chksum_offload",
>
> /* packet statistics */
> "broadcast", "rx_prio_0", "rx_prio_1", "rx_prio_2", "rx_prio_3",
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 0efbae9..d1eb25d 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1893,6 +1893,7 @@ static void mlx4_en_clear_stats(struct net_device *dev)
> priv->rx_ring[i]->packets = 0;
> priv->rx_ring[i]->csum_ok = 0;
> priv->rx_ring[i]->csum_none = 0;
> + priv->rx_ring[i]->csum_complete = 0;
> }
> }
>
> @@ -2503,6 +2504,10 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> /* Query for default mac and max mtu */
> priv->max_mtu = mdev->dev->caps.eth_mtu_cap[priv->port];
>
> + if (mdev->dev->caps.rx_checksum_flags_port[priv->port] &
> + MLX4_RX_CSUM_MODE_VAL_NON_TCP_UDP)
> + priv->flags |= MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP;
> +
> /* Set default MAC */
> dev->addr_len = ETH_ALEN;
> mlx4_en_u64_to_mac(dev->dev_addr, mdev->dev->caps.def_mac[priv->port]);
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_port.c b/drivers/net/ethernet/mellanox/mlx4/en_port.c
> index 134b12e..6cb8007 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_port.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_port.c
> @@ -155,11 +155,13 @@ int mlx4_en_DUMP_ETH_STATS(struct mlx4_en_dev *mdev, u8 port, u8 reset)
> stats->rx_bytes = 0;
> priv->port_stats.rx_chksum_good = 0;
> priv->port_stats.rx_chksum_none = 0;
> + priv->port_stats.rx_chksum_complete = 0;
> for (i = 0; i < priv->rx_ring_num; i++) {
> stats->rx_packets += priv->rx_ring[i]->packets;
> stats->rx_bytes += priv->rx_ring[i]->bytes;
> priv->port_stats.rx_chksum_good += priv->rx_ring[i]->csum_ok;
> priv->port_stats.rx_chksum_none += priv->rx_ring[i]->csum_none;
> + priv->port_stats.rx_chksum_complete += priv->rx_ring[i]->csum_complete;
> }
> stats->tx_packets = 0;
> stats->tx_bytes = 0;
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index 2a29a1a..f8a0449 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -42,6 +42,10 @@
> #include <linux/vmalloc.h>
> #include <linux/irq.h>
>
> +#if IS_ENABLED(CONFIG_IPV6)
> +#include <net/ip6_checksum.h>
> +#endif
> +
> #include "mlx4_en.h"
>
> static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
> @@ -642,6 +646,86 @@ static void mlx4_en_refill_rx_buffers(struct mlx4_en_priv *priv,
> }
> }
>
> +/* When hardware doesn't strip the vlan, we need to calculate the checksum
> + * over it and add it to the hardware's checksum calculation
> + */
> +static inline __wsum get_fixed_vlan_csum(__wsum hw_checksum,
> + struct vlan_hdr *vlanh)
> +{
> + return csum_add(hw_checksum, *(__wsum *)vlanh);
> +}
> +
> +/* Although the stack expects checksum which doesn't include the pseudo
> + * header, the HW adds it. To address that, we are subtracting the pseudo
> + * header checksum from the checksum value provided by the HW.
> + */
> +static void get_fixed_ipv4_csum(__wsum hw_checksum, struct sk_buff *skb,
> + struct iphdr *iph)
> +{
> + __u16 length_for_csum = 0;
> + __wsum csum_pseudo_header = 0;
> +
> + length_for_csum = (be16_to_cpu(iph->tot_len) - (iph->ihl << 2));
> + csum_pseudo_header = csum_tcpudp_nofold(iph->saddr, iph->daddr,
> + length_for_csum, iph->protocol, 0);
> + skb->csum = csum_sub(hw_checksum, csum_pseudo_header);
> +}
> +
> +#if IS_ENABLED(CONFIG_IPV6)
> +/* In IPv6 packets, besides subtracting the pseudo header checksum,
> + * we also compute/add the IP header checksum which
> + * is not added by the HW.
> + */
> +static int get_fixed_ipv6_csum(__wsum hw_checksum, struct sk_buff *skb,
> + struct ipv6hdr *ipv6h)
> +{
> + __wsum csum_pseudo_header = 0;
> +
> + if (ipv6h->nexthdr == IPPROTO_FRAGMENT || ipv6h->nexthdr == IPPROTO_HOPOPTS)
> + return -1;
> + hw_checksum = csum_add(hw_checksum, (__force __wsum)(ipv6h->nexthdr << 8));
> +
> + csum_pseudo_header = csum_ipv6_magic_nofold(&ipv6h->saddr,
> + &ipv6h->daddr,
> + ntohs(ipv6h->payload_len),
> + ipv6h->nexthdr,
> + 0);
> + skb->csum = csum_sub(hw_checksum, csum_pseudo_header);
> + skb->csum = csum_add(skb->csum, csum_partial(ipv6h, sizeof(struct ipv6hdr), 0));
> + return 0;
> +}
> +#endif
> +
> +static int check_csum(struct mlx4_cqe *cqe, struct sk_buff *skb, int hwtstamp_rx_filter)
> +{
> + __wsum hw_checksum = 0;
> +
> + void *hdr = (u8 *)skb->data + sizeof(struct ethhdr);
> +
> + hw_checksum = csum_unfold((__force __sum16)cqe->checksum);
> +
> + if (((struct ethhdr *)skb->data)->h_proto == htons(ETH_P_8021Q) &&
> + hwtstamp_rx_filter != HWTSTAMP_FILTER_NONE) {
> + /* next protocol non IPv4 or IPv6 */
> + if (((struct vlan_hdr *)hdr)->h_vlan_encapsulated_proto
> + != htons(ETH_P_IP) ||
> + ((struct vlan_hdr *)hdr)->h_vlan_encapsulated_proto
> + != htons(ETH_P_IPV6))
> + return -1;
> + hw_checksum = get_fixed_vlan_csum(hw_checksum, hdr);
> + hdr += sizeof(struct vlan_hdr);
> + }
> +
> + if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4))
> + get_fixed_ipv4_csum(hw_checksum, skb, hdr);
> +#if IS_ENABLED(CONFIG_IPV6)
> + else if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV6))
> + if (get_fixed_ipv6_csum(hw_checksum, skb, hdr))
> + return -1;
> +#endif
> + return 0;
> +}
> +
> int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int budget)
> {
> struct mlx4_en_priv *priv = netdev_priv(dev);
> @@ -743,13 +827,26 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
>
> if (likely(dev->features & NETIF_F_RXCSUM)) {
> - if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
> - (cqe->checksum == cpu_to_be16(0xffff))) {
> - ring->csum_ok++;
> - ip_summed = CHECKSUM_UNNECESSARY;
> + if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_TCP |
> + MLX4_CQE_STATUS_UDP)) {
> + if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
> + cqe->checksum == cpu_to_be16(0xffff)) {
> + ip_summed = CHECKSUM_UNNECESSARY;
> + ring->csum_ok++;
> + } else {
> + ip_summed = CHECKSUM_NONE;
> + ring->csum_none++;
> + }
> } else {
> - ip_summed = CHECKSUM_NONE;
> - ring->csum_none++;
> + if (priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP &&
> + (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
> + MLX4_CQE_STATUS_IPV6))) {
> + ip_summed = CHECKSUM_COMPLETE;
> + ring->csum_complete++;
> + } else {
> + ip_summed = CHECKSUM_NONE;
> + ring->csum_none++;
> + }
> }
> } else {
> ip_summed = CHECKSUM_NONE;
> @@ -767,6 +864,13 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> goto next;
> }
>
> + if (ip_summed == CHECKSUM_COMPLETE) {
> + if (check_csum(cqe, skb, ring->hwtstamp_rx_filter)) {
> + ip_summed = CHECKSUM_NONE;
> + ring->csum_none++;
> + }
> + }
> +
> skb->ip_summed = ip_summed;
> skb->protocol = eth_type_trans(skb, dev);
> skb_record_rx_queue(skb, cq->ring);
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 9f82196..2f6ba42 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -1629,6 +1629,7 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
> struct mlx4_init_hca_param init_hca;
> u64 icm_size;
> int err;
> + struct mlx4_config_dev_params params;
>
> if (!mlx4_is_slave(dev)) {
> err = mlx4_QUERY_FW(dev);
> @@ -1762,6 +1763,14 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
> goto unmap_bf;
> }
>
> + /* Query CONFIG_DEV parameters */
> + err = mlx4_config_dev_retrieval(dev, ¶ms);
> + if (err && err != -ENOTSUPP) {
> + mlx4_err(dev, "Failed to query CONFIG_DEV parameters\n");
> + } else if (!err) {
> + dev->caps.rx_checksum_flags_port[1] = params.rx_csum_flags_port_1;
> + dev->caps.rx_checksum_flags_port[2] = params.rx_csum_flags_port_2;
> + }
> priv->eq_table.inta_pin = adapter.inta_pin;
> memcpy(dev->board_id, adapter.board_id, sizeof dev->board_id);
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> index ef83d12..de45674 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> @@ -326,6 +326,7 @@ struct mlx4_en_rx_ring {
> #endif
> unsigned long csum_ok;
> unsigned long csum_none;
> + unsigned long csum_complete;
> int hwtstamp_rx_filter;
> cpumask_var_t affinity_mask;
> };
> @@ -449,6 +450,7 @@ struct mlx4_en_port_stats {
> unsigned long rx_alloc_failed;
> unsigned long rx_chksum_good;
> unsigned long rx_chksum_none;
> + unsigned long rx_chksum_complete;
> unsigned long tx_chksum_offload;
> #define NUM_PORT_STATS 9
> };
> @@ -507,7 +509,8 @@ enum {
> MLX4_EN_FLAG_ENABLE_HW_LOOPBACK = (1 << 2),
> /* whether we need to drop packets that hardware loopback-ed */
> MLX4_EN_FLAG_RX_FILTER_NEEDED = (1 << 3),
> - MLX4_EN_FLAG_FORCE_PROMISC = (1 << 4)
> + MLX4_EN_FLAG_FORCE_PROMISC = (1 << 4),
> + MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP = (1 << 5),
> };
>
> #define MLX4_EN_MAC_HASH_SIZE (1 << BITS_PER_BYTE)
> diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
> index 5cc5eac..3d9bff0 100644
> --- a/include/linux/mlx4/device.h
> +++ b/include/linux/mlx4/device.h
> @@ -497,6 +497,7 @@ struct mlx4_caps {
> u16 hca_core_clock;
> u64 phys_port_id[MLX4_MAX_PORTS + 1];
> int tunnel_offload_mode;
> + u8 rx_checksum_flags_port[MLX4_MAX_PORTS + 1];
> };
>
> struct mlx4_buf_list {
> --
> 1.7.1
>
Acked-by: H.K. Jerry Chu <hkchu@google.com>
BTW, will the patch work for all versions of the chip?
Jerry
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Andrew Lunn @ 2014-10-30 21:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: netdev, David S. Miller, Florian Fainelli, Andrew Lunn,
linux-kernel
In-Reply-To: <1414604707-22407-10-git-send-email-linux@roeck-us.net>
> +static int dsa_slave_get_eeprom_len(struct net_device *dev)
> +{
> + struct dsa_slave_priv *p = netdev_priv(dev);
> + struct dsa_switch *ds = p->parent;
> +
> + if (ds->pd->eeprom_len)
> + return ds->pd->eeprom_len;
> +
> + if (ds->drv->get_eeprom_len)
> + return ds->drv->get_eeprom_len(ds);
> +
> + return 0;
> +}
> +
Hi Guenter
I just started doing some testing with this patchset. A bit late since
David just accepted it, but...
root@dir665:~# ethtool -e lan4
Cannot get EEPROM data: Invalid argument
root@dir665:~# ethtool -e eth0
Cannot get EEPROM data: Operation not supported
There is no eeprom for the hardware i'm testing. Operation not
supported seems like a better error code and Invalid argument, and is
what other network drivers i tried returned.
Andrew
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Eric Dumazet @ 2014-10-30 21:07 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20141030205204.GE10069@breakpoint.cc>
On Thu, 2014-10-30 at 21:52 +0100, Florian Westphal wrote:
> So, what about changing the default to 1 in net-next?
>
> We could add automatic 'no-ecn' to retransmitted syns to avoid
> ecn blackholes (Daniel Borkmann has a patch for this), and, in case
> ecn=1 causes too much breakage we can always revert (and re-consider ecn
> per route settings as an intermediate step).
>
> What do you think?
I think this is way too dangerous.
I played a lot with ECN in the past (and fixed number of bugs in linux)
and discovered many times I had to disable it to be able to surf the
Internet.
I am kind of an expert so always could figure out what was the problem,
but average user wont have the choice.
Reverting might take a long long time, it wont help people stuck behind
buggy equipment.
^ permalink raw reply
* [PATCH net-next] hyperv: Add IPv6 into the hash computation for vRSS
From: Haiyang Zhang @ 2014-10-30 21:07 UTC (permalink / raw)
To: davem, netdev; +Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
This will allow the workload spreading via vRSS for IPv6.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 4 +++-
drivers/net/hyperv/rndis_filter.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 78ec33f..3295e4e 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -193,7 +193,9 @@ static bool netvsc_set_hash(u32 *hash, struct sk_buff *skb)
struct flow_keys flow;
int data_len;
- if (!skb_flow_dissect(skb, &flow) || flow.n_proto != htons(ETH_P_IP))
+ if (!skb_flow_dissect(skb, &flow) ||
+ !(flow.n_proto == htons(ETH_P_IP) ||
+ flow.n_proto == htons(ETH_P_IPV6)))
return false;
if (flow.ip_proto == IPPROTO_TCP)
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 2b86f0b..ccce6f2 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -728,7 +728,8 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev, int num_queue)
rssp->hdr.size = sizeof(struct ndis_recv_scale_param);
rssp->flag = 0;
rssp->hashinfo = NDIS_HASH_FUNC_TOEPLITZ | NDIS_HASH_IPV4 |
- NDIS_HASH_TCP_IPV4;
+ NDIS_HASH_TCP_IPV4 | NDIS_HASH_IPV6 |
+ NDIS_HASH_TCP_IPV6;
rssp->indirect_tabsize = 4*ITAB_NUM;
rssp->indirect_taboffset = sizeof(struct ndis_recv_scale_param);
rssp->hashkey_size = HASH_KEYLEN;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] tipc: spelling errors
From: David Miller @ 2014-10-30 20:56 UTC (permalink / raw)
To: stephen; +Cc: jon.maloy, allan.stephens, netdev
In-Reply-To: <20141029225851.03651f3f@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 29 Oct 2014 22:58:51 -0700
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next] r8152: set RTL8152_UNPLUG when finding -ENODEV
From: David Miller @ 2014-10-30 20:55 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-73-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Thu, 30 Oct 2014 11:46:40 +0800
> Set RTL8152_UNPLUG when finding -ENODEV. This could accelerate
> unloading the driver when the device is unplugged.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] syncookies: only increment SYNCOOKIESFAILED on validation error
From: David Miller @ 2014-10-30 20:54 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1414634138-23238-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 30 Oct 2014 02:55:38 +0100
> Only count packets that failed cookie-authentication.
> We can get SYNCOOKIESFAILED > 0 while we never even sent a single cookie.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] cxgb4 : Fix missing initialization of win0_lock
From: David Miller @ 2014-10-30 20:52 UTC (permalink / raw)
To: anish; +Cc: netdev, hariprasad, leedom
In-Reply-To: <1414630443-6412-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Wed, 29 Oct 2014 17:54:03 -0700
> win0_lock was being used un-initialized, resulting in warning traces
> being seen when lock debugging is enabled (and just wrong)
>
> Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to access the HW
> memory with PCIe Window method')
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 20:52 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev
In-Reply-To: <20141030.155958.156984068627586090.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Wed, 29 Oct 2014 13:23:07 +0100
>
> > We could do that, if you prefer.
> >
> > I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> > then we want to enable 'passive' ecn for incoming connections only on
> > a particular route without announcing ecn to the peer. I haven't been
> > able to find any -- I think if you deem 'route to x' safe for ecn it
> > might as well be enabled for both initiator and responder. The original
> > patch would be sufficient for that.
> >
> > IOW, is 'ecn from a to b but not b to a' a sensible requirement?
>
> I think you have to apply the same logic for the sysctl (there's a
> reason to only support ECN passively) as you do for the route feature
> because you can logically look at the sysctl as applying to the
> default route.
Agreed, sysctl is comparable to default route.
And I think 'passive ecn' makes perfect sense for a default route.
But for a specific host/network?
Either I know that path to $x is ecn-safe (i.e. turn it on for both ends)
or I don't, in which case the global 'passive' default ("if peer requests
it they probably know what they're doing") is fine.
> > default at one point (almost no routers set CE bit at this time, perhaps
> > that would change if ecn usage is more widespread).
>
> Now you're talking.
>
> So, either passive ECN support makes sense or it does not. To me, no
> matter what the argument, it doesn't matter what realm (whole system,
> specific routes) you apply that argument to.
The passive mode was added 5 years ago via
commit 255cac91c3c9ce7dca7713b93ab03c75b7902e0e
(tcp: extend ECN sysctl to allow server-side only ECN), and I think the
commit log rationale makes sense.
So, what about changing the default to 1 in net-next?
We could add automatic 'no-ecn' to retransmitted syns to avoid
ecn blackholes (Daniel Borkmann has a patch for this), and, in case
ecn=1 causes too much breakage we can always revert (and re-consider ecn
per route settings as an intermediate step).
What do you think?
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ariel.elior
In-Reply-To: <1414627670.631.105.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 17:07:50 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> bnx2x_msix_fp_int() and bnx2x_interrupt() run from hard interrupt
> context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv
In-Reply-To: <1414626885.631.102.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 16:54:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4_en_rx_irq() and mlx4_en_tx_irq() run from hard interrupt context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/7] can: m_can: update to support CAN FD features
From: Oliver Hartkopp @ 2014-10-30 20:32 UTC (permalink / raw)
To: Dong Aisheng; +Cc: linux-can, mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <20141030024226.GA29572@shlinux1.ap.freescale.net>
On 10/30/2014 03:42 AM, Dong Aisheng wrote:
> On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
>> So first I would suggest to check the core release register (CREL) to be
>> version 3.0.x and quit the driver initialization if it doesn't fit this
>> version. I would suggest to provide a separate patch for that check. What
>> about printing the core release version into the kernel log at driver
>> initialization time?
>>
>
> One question is that if v3.1.0 and v3.2.0 will be backward compatible with
> v3.0.1, if yes, how about let the driver still work for them instead of
> simply quit?
There are several important differences between 3.0.x and 3.1.x.
E.g. the CCCR, BTP, PSR and others are changed and a register for the
transmitter delay compensation is added.
I assume from 3.1.x to 3.2.x the controller registers will only change in
small details as the main update will be on the wire and not in the functionality.
> And then we can add new features according new released IP version.
Yes. We probably can wait for 3.[12].x to become available before adding the
special code that behaves according the core release register content.
>>> @@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
>>> if (rxfs & RXFS_RFL)
>>> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
>>>
>>> - skb = alloc_can_skb(dev, &frame);
>>> + skb = alloc_canfd_skb(dev, &frame);
>>
>> You are *always* allocating CAN FD frames now?
>>
>
> Yes, currently it is.
> The test seemed ok using CAN FD frames even receive normal frame.
When you put CAN frame content into a CAN FD skb it becomes a CAN FD frame -
which is wrong.
CAN 2.0 frame (EDL is clear) -> alloc_can_skb()
CAN FD frame (EDL is set) -> alloc_canfd_skb()
You can have a CAN FD frame with a DLC of 8, which does *not* mean that you
have a CAN 2.0 frame.
> The issue i know is that candump seemed can not recognize remote frame reported
> by the driver.
Do you use the latest candump from
https://gitorious.org/linux-can/can-utils/
??
The latest candump switches the CAN_RAW socket into the mode to accept both
CAN *and* CAN FD frames and displays the frames correctly.
> Not sure if it's caused by canfd_frame used.
Yes. CAN FD frames do not have a RTR bit.
> Will test and check.
>
>> Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
>> FD frame.
>>
>> Of course you can use the struct canfd_frame in m_can_read_fifo() as the
>> layout of the struct can_frame is identical when filled with 'normal' CAN
>> frame content.
>>
>> But you need to distinguish whether it is a CAN or CAN FD frame when
>> allocating the skb based on the RX_BUF_EDL value.
>>
>
> Yes, i think it's good to do that.
> One obvious benefit is it saves memory at least.
The main point is that CAN frames and CAN FD frames are separated by this
(MTU) length information. It's not about saving memory.
A CAN FD frame with DLC 8 still has 64 data bytes inside it's data structure.
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-10-30 20:32 UTC (permalink / raw)
To: Denis Kirjanov
Cc: netdev@vger.kernel.org, linuxppc-dev, Michael Ellerman,
Matt Evans
In-Reply-To: <1414649535-3956-1-git-send-email-kda@linux-powerpc.org>
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> skb->pkt_type field.
>
> Before:
> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>
> After:
> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
if you'd only quoted #12, it would all make sense ;)
but #11 test is not using PKTTYPE. So your patch shouldn't
make a difference. Are these numbers with JIT on and off?
^ permalink raw reply
* Re: [PATCH net-next] ipv4: minor spelling fixes
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20141029160506.46011813@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 29 Oct 2014 16:05:06 -0700
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next] tcp: allow for bigger reordering level
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1414610869.631.94.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 12:27:49 -0700
> Yuchung and othres are working on a new way to handle reorders (RACK),
> and should present the concept in next IETF meeting.
>
> A linux patch should follow shortly.
>
> High level idea is :
>
> Decide when and what to retransmit based on the timing, instead of
> sequence, relationships. This covers both original or retransmitted
> packets.
>
> On dupacks, wait a fraction of RTT before the repair process to both
> allow reordering and relieve the network
My instint says that this delay will increase recovery time, but I
guess they've taken that into consideration :-)
^ permalink raw reply
* Re: PATCH: Add IFF_ALLMULTI support to cpsw (and fix IFF_PROMISC support too)
From: David Miller @ 2014-10-30 20:12 UTC (permalink / raw)
To: lsorense; +Cc: linux-kernel, mugunthanvnm, netdev
In-Reply-To: <20141029190612.GH24110@csclub.uwaterloo.ca>
From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Date: Wed, 29 Oct 2014 15:06:12 -0400
> The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
> multicast routing rather hard to handle. Related to this, when enabling
> IFF_PROMISC in non dual_emac mode, all registered vlans are flushed,
> and only broadcast and unicast are allowed which isn't what you would
> want from IFF_PROMISC.
>
> A new cpsw_ale_set_allmulti function now scans through the ALE entry
> table and adds or removes the host port from the unregistered multicast
> port mask depending on the state of IFF_ALLMULTI. In promisc mode,
> it is also called to enable reception of all multicast traffic.
>
> With this change I am now able to run dynamic multicast routing and also
> use tcpdump and actually see multicast traffic.
>
> Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Please fix your Subject line and resubmit this patch.
Subject lines end up as the commit message header text, and
therefore must be of the form:
subsystem: Description.
In this case "cpsw: " is probably an appropriate subsystem
prefix.
^ permalink raw reply
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: David Miller @ 2014-10-30 20:11 UTC (permalink / raw)
To: logan; +Cc: netdev
In-Reply-To: <20141029172915.GA15714@mx.elandsys.com>
From: Loganaden Velvindron <logan@elandsys.com>
Date: Wed, 29 Oct 2014 10:29:15 -0700
> (It's my first time sending a diff to netdev, please let me know if
> I made a mistake)
Please don't put text like this into the commit log message body.
^ permalink raw reply
* Re: [PATCH v2] ip6_tunnel: allow to change mode for the ip6tnl0
From: David Miller @ 2014-10-30 20:09 UTC (permalink / raw)
To: alan; +Cc: netdev, edumazet
In-Reply-To: <1414569292-15384-1-git-send-email-alan@al-an.info>
From: "Alexey Andriyanov" <alan@al-an.info>
Date: Wed, 29 Oct 2014 10:54:52 +0300
> The fallback device is in ipv6 mode by default.
> The mode can not be changed in runtime, so there
> is no way to decapsulate ip4in6 packets coming from
> various sources without creating the specific tunnel
> ifaces for each peer.
>
> This allows to update the fallback tunnel device, but only
> the mode could be changed. Usual command should work for the
> fallback device: `ip -6 tun change ip6tnl0 mode any`
>
> The fallback device can not be hidden from the packet receiver
> as a regular tunnel, but there is no need for synchronization
> as long as we do single assignment.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Alexey Andriyanov <alan@al-an.info>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: David Miller @ 2014-10-30 19:59 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20141029122307.GA29253@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 29 Oct 2014 13:23:07 +0100
> We could do that, if you prefer.
>
> I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> then we want to enable 'passive' ecn for incoming connections only on
> a particular route without announcing ecn to the peer. I haven't been
> able to find any -- I think if you deem 'route to x' safe for ecn it
> might as well be enabled for both initiator and responder. The original
> patch would be sufficient for that.
>
> IOW, is 'ecn from a to b but not b to a' a sensible requirement?
I think you have to apply the same logic for the sysctl (there's a
reason to only support ECN passively) as you do for the route feature
because you can logically look at the sysctl as applying to the
default route.
> Unrelated to this patch, but I'd like to see sysctl_tcp_ecn=1 as a
> default at one point (almost no routers set CE bit at this time, perhaps
> that would change if ecn usage is more widespread).
Now you're talking.
So, either passive ECN support makes sense or it does not. To me, no
matter what the argument, it doesn't matter what realm (whole system,
specific routes) you apply that argument to.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove assignment in if condition
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414583871-14196-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 12:57:51 +0100
> Do assignment before if condition and test !skb like in rawv6_recvmsg()
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove inline on static in c file
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414579097-11659-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 11:38:17 +0100
> remove __inline__ / inline and let compiler decide what to do
> with static functions
>
> Inspired-by: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH/TRIVIAL 1/1 net-next] ipv6: spelling s/incomming/incoming
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, trivial, netdev
In-Reply-To: <1414573227-10743-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 10:00:26 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ 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