* Re: [net-next 1/2] sctp: add transport state in /proc/net/sctp/remaddr
From: David Miller @ 2014-10-30 23:40 UTC (permalink / raw)
To: michele; +Cc: vyasevich, nhorman, linux-sctp, netdev
In-Reply-To: <1414661356-17255-1-git-send-email-michele@acksyn.org>
From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 30 Oct 2014 10:29:15 +0100
> It is often quite helpful to be able to know the state of a transport
> outside of the application itself (for troubleshooting purposes or for
> monitoring purposes). Add it under /proc/net/sctp/remaddr.
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
Applied.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:30 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 -next 0/2] net: allow setting ecn via routing table
From: Eric Dumazet @ 2014-10-30 23:30 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20141030231637.GF10069@breakpoint.cc>
On Fri, 2014-10-31 at 00:16 +0100, Florian Westphal wrote:
> I see. So that makes ecn=1 default a pure fantasy.
Well, I had this dream about 2 or 3 years ago, but I eventually came to
this (sad) conclusion.
^ permalink raw reply
* Re: [PATCH net-next 8/8] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE
From: Or Gerlitz @ 2014-10-30 23:28 UTC (permalink / raw)
To: Jerry Chu
Cc: Or Gerlitz, David S. Miller, netdev@vger.kernel.org, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli
In-Reply-To: <CAPshTChwewGiP712ki-BGu6VWhZTVOfZDzFm8NEqvon7uLhEWA@mail.gmail.com>
On Thu, Oct 30, 2014 at 11:20 PM, Jerry Chu <hkchu@google.com> wrote:
> Acked-by: H.K. Jerry Chu <hkchu@google.com>
>
> BTW, will the patch work for all versions of the chip?
If you'll look carefully, you'll see we go that path only when
priv->flags & MLX4_EN_FLAG_RX_CSUM_NON_TCP_UDP is true. This currently
holds only for ConnectX3 and not ConnectX3-pro. Down the road, the
feature will also be available for the -pro too.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
From: Or Gerlitz @ 2014-10-30 23:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli, Ido Shamay
In-Reply-To: <1414695631.15352.5.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Oct 30, 2014 at 9:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
>> Remove the code which goes through napi_gro_frags() on the RX path,
>> use only napi_gro_receive().
> Hmpff... napi_gro_frags() should be faster.
> Have you benchmarked this ?
yep we did, napi_gro_frags() was somehow better for single stream. Do
you think we need to do it the other way around, e.g converge to use
napi_gro_frags()?
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 23:23 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 RESEND v2] ipv4: Do not cache routing failures due to disabled forwarding.
From: David Miller @ 2014-10-30 23:21 UTC (permalink / raw)
To: nicolas.cavallari; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1414660193-4177-1-git-send-email-nicolas.cavallari@green-communications.fr>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Thu, 30 Oct 2014 10:09:53 +0100
> If we cache them, the kernel will reuse them, independently of
> whether forwarding is enabled or not. Which means that if forwarding is
> disabled on the input interface where the first routing request comes
> from, then that unreachable result will be cached and reused for
> other interfaces, even if forwarding is enabled on them. The opposite
> is also true.
>
> This can be verified with two interfaces A and B and an output interface
> C, where B has forwarding enabled, but not A and trying
> ip route get $dst iif A from $src && ip route get $dst iif B from $src
>
> Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Reviewed-by: Julian Anastasov <ja@ssi.bg>
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 23:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev
In-Reply-To: <1414710342.15352.14.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-10-30 at 23:15 +0100, Florian Westphal wrote:
>
> > Do you think a fallback to non-ecn for retransmitted syns would help?
>
> Unfortunately some firewalls are buggy and accept a single SYN per flow.
[..]
> Note that ECN problems are not only contained in SYN packets being
> eventually dropped. You might have a success to establish a flow, and
> later get CE marks for all packets and cwnd converges to 1.
I see. So that makes ecn=1 default a pure fantasy.
Thanks for explaining this.
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Eric Dumazet @ 2014-10-30 23:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1414707602.16849.70.camel@decadent.org.uk>
On Thu, 2014-10-30 at 22:20 +0000, Ben Hutchings wrote:
> Could do. I'm trying to make small fixes that are suitable for stable.
Oh right, makes sense ;)
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Eric Dumazet @ 2014-10-30 23:05 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev
In-Reply-To: <20141030221501.GA9416@breakpoint.cc>
On Thu, 2014-10-30 at 23:15 +0100, Florian Westphal wrote:
> Do you think a fallback to non-ecn for retransmitted syns would help?
> If not, do you think having ecn tunable available via route is helpful?
Unfortunately some firewalls are buggy and accept a single SYN per flow.
You would need to blacklist ecn at first sign of a possible ecn problem,
for all following connections attempts.
Note that ECN problems are not only contained in SYN packets being
eventually dropped. You might have a success to establish a flow, and
later get CE marks for all packets and cwnd converges to 1.
This is really a lot of work to get all sorted out.
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:54 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 4/8] net/mlx4_en: Add __GFP_COLD gfp flags in alloc_pages
From: Or Gerlitz @ 2014-10-30 22:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Matan Barak,
Amir Vadai, Saeed Mahameed, Shani Michaeli, Ido Shamay
In-Reply-To: <1414689333.9028.0.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Oct 30, 2014 at 7:15 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> @@ -54,7 +54,7 @@ static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
>> dma_addr_t dma;
>>
>> for (order = MLX4_EN_ALLOC_PREFER_ORDER; ;) {
>> - gfp_t gfp = _gfp;
>> + gfp_t gfp = _gfp | __GFP_COLD;
> This should be set by callers, to avoid extra code
> GFP_ATOMIC | __GFP_COLD
> or
> GFP_KERNEL | __GFP_COLD
I guess we can do that, sure.
^ permalink raw reply
* Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
From: Murilo Opsfelder Araujo @ 2014-10-30 22:44 UTC (permalink / raw)
To: Larry Finger, linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1414642633-3700-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 10/30/2014 02:17 AM, Larry Finger wrote:
> Some late changes to rtlwifi made some of the older drivers not start correctly.
> These patches should be applied to 3.18.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Cc: Murilo Opsfelder Araujo <mopsfelder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Larry Finger (6):
> rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing
> get_btc_status
> rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
> rtlwifi: rtl8192se: Add missing section to read descriptor setting
> rtlwifi: rtl8192ce: Add missing section to read descriptor setting
> rtlwifi: rtl8821ae: Remove extra semicolons
> rtlwifi: rtl8192se: Fix firmware loading
>
> drivers/net/wireless/rtlwifi/core.c | 6 ++++++
> drivers/net/wireless/rtlwifi/core.h | 1 +
> drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 2 ++
> drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 +
> drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 3 +++
> drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 1 +
> drivers/net/wireless/rtlwifi/rtl8192se/def.h | 2 ++
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 +++-------------------
> drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 3 +++
> drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 ++++++------
> 10 files changed, 28 insertions(+), 25 deletions(-)
>
Hi, Larry.
I've applied this patchset on top of next-20141030 and got the same
result: kernel panic went away but the rtl8192se device does not associate.
Thanks anyway for dedicating your family time to trying to get this fixed.
We can talk about that later when you're back on regular schedule.
Appreciated!
--
Murilo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-30 22:39 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, David S. Miller, Florian Fainelli, linux-kernel
In-Reply-To: <20141030211131.GB32139@lunn.ch>
On Thu, Oct 30, 2014 at 10:11:31PM +0100, Andrew Lunn wrote:
> > +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.
>
Hi Andrew,
I think the problem is that the infrastructure code (net/core/ethtool.c)
does not accept an error from the get_eeprom_len function, but instead
assumes that reporting eeprom data is supported if a driver provides
the access functions. The get_eeprom_len function returns 0 in your case,
which in ethtool_get_any_eeprom() translates to -EINVAL because user space
either requests no data or more data than available. I wonder why user
space requests anything in the first place; I would have assumed that it
reads the driver information first and is told that the eeprom length is 0,
but I guess that is a different question.
I quickly browsed through a couple of other drivers supporting get_eprom_len,
and they all return 0 if there is no eeprom. Doesn't that mean that they all
end up reporting -EINVAL if an attempt is made to read the eeprom ?
The only solution that comes to my mind would be to have the infrastructure
code check the return value from get_eeprom_len and return -EOPNOTSUPP
if the reported eeprom length is 0. That would be an infrastructure change,
though. Does that sound reasonable, or do you have a better idea ?
In parallel, I'll have a look into the ethtool command to see why it
requests eeprom data even though the reported eeprom length is 0.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 net 1/2] drivers/net: Disable UFO through virtio
From: Ben Hutchings @ 2014-10-30 22:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Hannes Frederic Sowa, virtualization
In-Reply-To: <1414694849.15352.3.camel@edumazet-glaptop2.roam.corp.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 817 bytes --]
On Thu, 2014-10-30 at 11:47 -0700, Eric Dumazet wrote:
> On Thu, 2014-10-30 at 18:27 +0000, Ben Hutchings wrote:
>
>
> > + {
> > + static bool warned;
> > +
> > + if (!warned) {
> > + warned = true;
> > + netdev_warn(tun->dev,
> > + "%s: using disabled UFO feature; please fix this program\n",
> > + current->comm);
> > + }
> >
>
> It might be time to add netdev_warn_once() ;)
Could do. I'm trying to make small fixes that are suitable for stable.
> Alternatively, you could use
> pr_warn_once("%s: using disabled UFO feature; please fix this program\n",
> tun->dev->name, current->comm);
That's missing a "%s: ", but yes that would also work.
Ben.
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 22:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev
In-Reply-To: <1414703260.15352.9.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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.
[..]
> Reverting might take a long long time, it wont help people stuck behind
> buggy equipment.
Do you think a fallback to non-ecn for retransmitted syns would help?
If not, do you think having ecn tunable available via route is helpful?
Thanks!
^ permalink raw reply
* DONATION!!!
From: Mrs Birgit Rausing @ 2014-10-30 22:11 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 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
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