* tg3 issue with tcp checksums and vlan packets
From: Vlad Yasevich @ 2014-09-16 16:43 UTC (permalink / raw)
To: Prashant Sreedharan, Michael Chan; +Cc: netdev@vger.kernel.org
Prashant and Michael
I am seeing a strange issue with tg3 driver when I try to pass to it tcp packets
that have partial checksums and inline (non-accelerated) vlan header.
Looking at the packet at the receiver, it appears as if the tcp checksum is never
updated. If I strip the vlan header and set vlan_tci, then everything works ok.
You can easily reproduce this by configuring 802.1ad vlans on top of tg3 device.
This will force software tagging, tg3 will not fix checksums and tcp connections
will not be established.
I've looked at tg3 driver and it doesn't look like it tries to pass any checksum
offsets to the nic/firmware. So it looks like a possible firmware issue.
Can you please take a look.
Thanks
-vlad
^ permalink raw reply
* Re: tg3 issue with tcp checksums and vlan packets
From: Michael Chan @ 2014-09-16 16:54 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Prashant Sreedharan, netdev@vger.kernel.org
In-Reply-To: <541868A9.7080407@gmail.com>
On Tue, 2014-09-16 at 12:43 -0400, Vlad Yasevich wrote:
> Prashant and Michael
>
> I am seeing a strange issue with tg3 driver when I try to pass to it tcp packets
> that have partial checksums and inline (non-accelerated) vlan header.
>
Are you disabling NETIF_F_HW_VLAN_CTAG_TX? I believe TX checksum and
TSO won't work. We need to add some code to disable both when VLAN
acceleration is disabled.
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Eric Dumazet @ 2014-09-16 17:04 UTC (permalink / raw)
To: Neal Cardwell
Cc: Yuchung Cheng, Andrey Dmitrov, Hannes Frederic Sowa, netdev,
Alexandra N. Kossovsky, Konstantin Ushakov
In-Reply-To: <CADVnQy=QM8sE93Rn+MyyHdgzW6xqioCsKSQ6xdMTbX5E7iM4WQ@mail.gmail.com>
On Tue, 2014-09-16 at 12:31 -0400, Neal Cardwell wrote:
> On Tue, Sep 16, 2014 at 11:11 AM, Yuchung Cheng <ycheng@google.com> wrote:
> > On Tue, Sep 16, 2014 at 6:09 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> Normally SO_LINGER could be used, or TCP_USER_TIMEOUT. This requires a
> >> system call before doing the close().
> >>
> >> 1) TCP_USER_TIMEOUT would be the fit for this, but its current
> >> implementation do not take care of the probes sent, even in FIN_WAIT
> >> state when in this zero window mode. A patch would be needed.
> > Yes that's what I meant. I am proposing we should patch
> > TCP_USER_TIMEOUT to do this.
>
> We should probably be careful here. It would be a non-trivial change
> in semantics to have TCP_USER_TIMEOUT solve this issue.
>
> TCP_USER_TIMEOUT, in both the man page, the RFC, and the existing
> code, is about a user-specific limit on the maximum amount of time the
> TCP stack will attempt to transmit a single packet. (For example, the
> man page: "specifies the maximum amount of time in milliseconds that
> transmitted data may remain unacknowledged before TCP will forcibly
> close the corresponding connection"). Any existing apps that are
> setting TCP_USER_TIMEOUT are probably setting it to something in the
> range of seconds to a few minutes, and may reasonably expect their
> orphaned connections to last minutes to hours, as long as they are
> making progress (each of the packets is ACKed in the
> seconds-to-minutes range).
>
> By contrast, AFAICT what we are talking about here for these
> ZWP-forever/tarpit scenarios is to be able to cap the maximum overall
> lifetime of an orphan connection. That's a different parameter, and
> folks might want to set it in the minutes-to-hours range.
Right, but TCP_USER_TIMEOUT should be improved nevertheless ?
Then, we might add support for another safety mechanism, but the bulk
load of TARPIT attacks would be already handled.
^ permalink raw reply
* Re: phy link status not stable
From: Florian Fainelli @ 2014-09-16 17:09 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, David Miller
In-Reply-To: <541864D0.7080803@ti.com>
2014-09-16 9:26 GMT-07:00 Mugunthan V N <mugunthanvnm@ti.com>:
> Hi
>
> While doing ifdown/ifup test, phy link up status is very much delayed
> and also link up/down comes alternatively without physical link changes
> which leads to ifup failure. in v3.12 internal tree there is no failure.
> Pasting the logs below.
Assuming your driver calls phy_start() and phy_stop() from the
ndo_open() resp. ndo_stop() functions, these function calls are not
synchronous, as in they do not wait for the link to go UP resp. DOWN
before returning. The PHY state machine gets programmed to a new state
from phy_start() resp. phy_stop() and the next workqueue execution
will proceed with an actual state change.
>
> root@am437x-evm:~# ifup eth0
> [ 652.633204] net eth0: initializing cpsw version 1.15 (0)
> [ 652.717428] net eth0: phy found : id is : 0x221622
> udhcpc (v1.20.2) started
> Sending discover...
> Sending discover...
> [ 658.717859] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full -
> flow control rx/tx
> Sending discover...
> [ 660.717894] cpsw 4a100000.ethernet eth0: Link is Down
> [ 661.717937] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full -
> flow control rx/tx
> No lease, failing
> root@am437x-evm:~# udhcpc
> udhcpc (v1.20.2) started
> Sending discover...
> Sending select for 172.24.190.6...
> Lease of 172.24.190.6 obtained, lease time 3600
> /etc/udhcpc.d/50default: Adding DNS 192.0.2.2
> /etc/udhcpc.d/50default: Adding DNS 192.0.2.3
> root@am437x-evm:~#
>
> Is this a known issue or any pointers where to look for clues?
This is not a known issue AFAICT, is the link really flapping? Not
sure if [1] could explain what you are seeing?
[1]: http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=95e8b10393f88a0db88d97e9d1953f01c854315a
could ex
>
> Setup: TI-AM437x EVM
> Phy: Micrel KSZ9031 Gigabit PHY
>
> Thanks,
> Mugunthan V N
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Florian
^ permalink raw reply
* Re: [GIT PULL nf-next 00/21] Second Round of IPVS Updates for v3.18
From: Pablo Neira Ayuso @ 2014-09-16 17:25 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1410827675-3637-1-git-send-email-horms@verge.net.au>
Hi Simon,
On Tue, Sep 16, 2014 at 09:34:14AM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider these IPVS updates for v3.18.
>
> * Add simple weighted failover scheduler
> - Thanks to Kenny Mathis
> * Support v6 real servers in v4 pools and vice versa
> - Thanks to Alex Gartrell and Julian Anastasov
I need a slightly larger description of this series.
I think you can merge patches 13-19 too. They are mostly two liners
with a similar description, so they naturally belong to the same
logical change. I would like to reduce the patchbomb pull request for
David.
Thanks.
^ permalink raw reply
* [PATCH net-next] of: mdio: honor flags passed to of_phy_connect
From: Florian Fainelli @ 2014-09-16 17:49 UTC (permalink / raw)
To: netdev; +Cc: davem, devicetree, Florian Fainelli
Commit f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach,
connect, connect_direct}") removed the flags argument to the PHY library
calls to: phy_{attach,connect,connect_direct}.
Most Device Tree aware drivers call of_phy_connect() with the flag
argument set to 0, but some of them might want to set a different value
there in order for the PHY driver to key a specific behavior based on
the phy_device::dev_flags value.
Allow such drivers to set custom dev_flags as part of the
of_phy_connect() call since of_phy_connect() does start the PHY state
machine, it will call into the PHY driver config_init() callback which
is usually where a specific phy_flags value is important.
Fixes: f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach, connect, connect_direct}")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
David,
This is applicable to 3.9 and newer, thanks!
drivers/of/of_mdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 401b2453da45..a85d80012993 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -224,6 +224,8 @@ struct phy_device *of_phy_connect(struct net_device *dev,
if (!phy)
return NULL;
+ phy->dev_flags = flags;
+
return phy_connect_direct(dev, phy, hndlr, iface) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect);
--
1.9.1
^ permalink raw reply related
* [PATCH iproute2] ip monitor: Changed 'Unknown message' format to be more informative
From: Vadim Kochan @ 2014-09-16 18:23 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
In case if unknown message was handled then it will be displayed as:
Unknown message: type=0x00000044(68) flags=0x00000000(0) len=0x0000004c(76)
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipmonitor.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 70f2a7a..838934d 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -135,8 +135,10 @@ static int accept_msg(const struct sockaddr_nl *who,
return 0;
if (n->nlmsg_type != NLMSG_ERROR && n->nlmsg_type != NLMSG_NOOP &&
n->nlmsg_type != NLMSG_DONE) {
- fprintf(fp, "Unknown message: %08x %08x %08x\n",
- n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ fprintf(fp, "Unknown message: type=0x%08x(%d) flags=0x%08x(%d)"
+ "len=0x%08x(%d)\n", n->nlmsg_type, n->nlmsg_type,
+ n->nlmsg_flags, n->nlmsg_flags, n->nlmsg_len,
+ n->nlmsg_len);
}
return 0;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Tom Herbert @ 2014-09-16 18:34 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Jesse Gross, David Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMgEUsBic5N_eXm=OYx94FL7ERkz5CUNCo4OBhqCVwC42g@mail.gmail.com>
On Tue, Sep 16, 2014 at 5:44 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Sep 16, 2014 at 1:44 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>
>>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>>> encapsulation over UDP, not VXLAN.
>>> If the NIC implements things properly following the generic interface then I believe it should work
>>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>>> This presumes that any encapsulation headers doesn't require any per
>>> segment update (so no GRE csum for instance). The stack will set up
>>> inner headers as needed, which should enough to provide to devices the
>>> offsets inner IP and TCP header which are needed for the the TSO
>>> operation (outer IP and UDP can be deduced also).
>
>
>
>> From the NICs that I am familiar with this is mostly true. The main
>> part that is missing from the current implementation is a length
>> limit: just because the hardware can skip over headers to an offset
>> doesn't mean that it can do so to an arbitrary depth. For example, in
>> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
>> probably assume that this is limited to 8 bytes. With the Intel NICs
>> that were just announced with Geneve support, this limit has been
>> increased to 64. If we add a parameter to the driver interface to
>> expose this then it should be generic across tunnels.
>
> I'm not sure to see why the length limit became our primary concern here...
>
Like Jesse mentioned above, looks like some NICs may have assumed all
encapsulation headers are eight bytes (which allows HW to implement
everything in fixed offsets). But this length is not a universal
constant: FOU is zero length encapsulation headers, GUE or geneve is
variable. The driver should really be checking if NIC can handle the
length and if it can't perform GSO in software-- I don't think we'll
need to expose this in the features.
> Fact is that we have nice set of NICs drivers in the kernel that do advertize
> the GSO_UDP_TUNNEL feature but their HW isn't capable to segment all of:
> FOU, GUE, VXLAN, VXLAN-gpe, geneve, LISP, L2TP, nvgre, or whatever
> else people might dream up, right?
>
> So we need to fix that and let each NIC properly advertize up to the
> stack what they
> can segment in HW and what not which means that networking code would have to
> do that in SW for (say) 64KB guest TCP segment that just went through
> this encapsulation.
>
> As long as Linux didn't support any UDP encapsulation other then VXLAN
> it worked,
> but soon will too easily broken, and I vote for the fix to be part of
> the FOU series, so we have
> the kernel functional also once it applied...
>
> Even if the encapsulated headers need no update per segment (and they always
> do, e.g the IP ID field of the outer IP header) still a certain HW may
> not be able
> to do TCP segmentation under any encapsulation scheme.
>
> And in that respect, I am not sure to follow on the " If the NIC
> implements things properly
> following the generic interface" comment.
>
> Or.
^ permalink raw reply
* Re: tg3 issue with tcp checksums and vlan packets
From: Vlad Yasevich @ 2014-09-16 18:45 UTC (permalink / raw)
To: Michael Chan; +Cc: Prashant Sreedharan, netdev@vger.kernel.org
In-Reply-To: <1410886475.7520.73.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On 09/16/2014 12:54 PM, Michael Chan wrote:
> On Tue, 2014-09-16 at 12:43 -0400, Vlad Yasevich wrote:
>> Prashant and Michael
>>
>> I am seeing a strange issue with tg3 driver when I try to pass to it tcp packets
>> that have partial checksums and inline (non-accelerated) vlan header.
>>
>
> Are you disabling NETIF_F_HW_VLAN_CTAG_TX? I believe TX checksum and
> TSO won't work. We need to add some code to disable both when VLAN
> acceleration is disabled.
>
>
No, in this case, I am simply creating an 802.1ad vlan on top. Since
tg3 doesn't provide ETIF_F_HW_VLAN_STAG_TX, we follow the non-accelerated
path.
Currently the driver doesn't appear to be offer ability to disable vlan acceleration.
However, if any software devices on top of the card do not support it for some reason,
then the issue would be seen as well.
-vlad
^ permalink raw reply
* Re: [PATCHv4 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: David L Stevens @ 2014-09-16 18:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <541785D8.5030101@oracle.com>
On 09/15/2014 08:35 PM, David L Stevens wrote:
> */
> #define VNET_TX_TIMEOUT (5 * HZ)
>
> -#define VNET_MAXPACKET 1518ULL /* ETH_FRAMELEN + VLAN_HDR */
> +#define VNET_MAXPACKET 65553ULL /* 64K-1 +ETH HDR +VLAN HDR*/
> #define VNET_TX_RING_SIZE 512
> #define VNET_TX_WAKEUP_THRESH(dr) ((dr)->pending / 4)
While looking at adding TSO support, I've turned up a bug with this.
The transmit buffer mapping should be using a cookie per-page and this increases
the page count (without page alignment) from 2 with a 1500-byte MTU to 10 with a 64K MTU
+ framing and allowing from unaligned buffers.
I think it worked during my testing because the pages were contiguous, but the tx buffer
allocation code is assuming 2 pages (and 2 cookies) max.
So, it's incorrect. I'll fix and repost; please don't apply these yet.
+-DLS
^ permalink raw reply
* Re: [PATCHv2] ipv4: Do not cache routing failures due to disabled forwarding.
From: David Miller @ 2014-09-16 18:54 UTC (permalink / raw)
To: nicolas.cavallari; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1410776893-5284-1-git-send-email-nicolas.cavallari@green-communications.fr>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Mon, 15 Sep 2014 12:28:13 +0200
> 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.
>
> 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>
> ---
> v2: simplify patch using julian anastasov's suggestion.
This also disables caching for the cases of a simple fib lookup failure.
Handle cached route invalidation the way it's meant to be, by bumping
the rt_genid.
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 214882e..aa4e63c 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1965,6 +1965,8 @@ static void inet_forward_change(struct net *net)
}
rcu_read_unlock();
}
+
+ rt_cache_flush(net);
}
static int devinet_conf_ifindex(struct net *net, struct ipv4_devconf *cnf)
^ permalink raw reply related
* Re: [net-next v7 0/4] Refactor vxlan and l2tp to use common UDP tunnel APIs
From: David Miller @ 2014-09-16 18:57 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1410777267-28237-1-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Mon, 15 Sep 2014 03:34:24 -0700
> Andy Zhou (4):
> udp_tunnel: Seperate ipv6 functions into its own file.
> udp-tunnel: Expand UDP tunnel APIs
> vxlan: Refactor vxlan driver to make use of the common UDP tunnel
> functions.
> l2tp: Refactor l2tp core driver to make use of the common UDP tunnel
> functions
Empty commit log messages like this, especially for the most important
posting (this one) where you are supposed to give a high level
description of what you are doing, why, and listing any pertinent
design decisions you had to make in your implementation.
Please respin this and give full, complete, commit log messages.
^ permalink raw reply
* Re: [PATCH v2 3/4] net: stmmac: add support for Intel Quark X1000
From: David Miller @ 2014-09-16 19:00 UTC (permalink / raw)
To: hock.leong.kweh
Cc: peppe.cavallaro, rayagond, vbridgers2013, srinivas.kandagatla,
wens, netdev, linux-kernel, boon.leong.ong
In-Reply-To: <F54AEECA5E2B9541821D670476DAE19C2B7E99A7@PGSMSX102.gar.corp.intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
Date: Mon, 15 Sep 2014 12:42:03 +0000
> The only things to differentiate them is PCI BUS DEVICE FUNCTION
> (Bus:Dev:Func) number which are fix numbers 00:20:6 for port 1 and
> 00:20:7 for port 2 stated in Quark X1000 datasheet.
Match on the PCI device class, which must be PCI_CLASS_NETWORK_ETHERNET
or similar.
The pci_device_id used for probing supports matching on this directly.
.
^ permalink raw reply
* [Patch net-next v2 1/4] net: fec: refine error handle of parser queue number from DT
From: Frank.Li @ 2014-09-16 17:58 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa; +Cc: shawn.guo, linux-arm-kernel, Frank Li
In-Reply-To: <1410890290-11248-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
check tx and rx queue seperately.
fix typo, "Invalidate" and "fail".
change pr_err to pr_warn.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 8f8e55e..d209d2e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2890,23 +2890,23 @@ fec_enet_get_queue_num(struct platform_device *pdev, int *num_tx, int *num_rx)
/* parse the num of tx and rx queues */
err = of_property_read_u32(np, "fsl,num-tx-queues", num_tx);
- err |= of_property_read_u32(np, "fsl,num-rx-queues", num_rx);
- if (err) {
+ if (err)
*num_tx = 1;
+
+ err = of_property_read_u32(np, "fsl,num-rx-queues", num_rx);
+ if (err)
*num_rx = 1;
- return;
- }
if (*num_tx < 1 || *num_tx > FEC_ENET_MAX_TX_QS) {
- dev_err(&pdev->dev, "Invalidate num_tx(=%d), fail back to 1\n",
- *num_tx);
+ dev_warn(&pdev->dev, "Invalid num_tx(=%d), fall back to 1\n",
+ *num_tx);
*num_tx = 1;
return;
}
if (*num_rx < 1 || *num_rx > FEC_ENET_MAX_RX_QS) {
- dev_err(&pdev->dev, "Invalidate num_rx(=%d), fail back to 1\n",
- *num_rx);
+ dev_warn(&pdev->dev, "Invalid num_rx(=%d), fall back to 1\n",
+ *num_rx);
*num_rx = 1;
return;
}
@@ -2924,8 +2924,8 @@ fec_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
static int dev_id;
struct device_node *np = pdev->dev.of_node, *phy_node;
- int num_tx_qs = 1;
- int num_rx_qs = 1;
+ int num_tx_qs;
+ int num_rx_qs;
of_id = of_match_device(fec_dt_ids, &pdev->dev);
if (of_id)
--
1.9.1
^ permalink raw reply related
* [Patch net-next v2 0/4] net: fec: add interrupt coalescence
From: Frank.Li @ 2014-09-16 17:58 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa; +Cc: shawn.guo, linux-arm-kernel, Frank Li
From: Frank Li <Frank.Li@freescale.com>
improve error handle when parse queue number.
add interrupt coalescence feature.
Change from v1 to v2
- fix indention
- use errata number instead of TKT
Frank Li (1):
net: fec: refine error handle of parser queue number from DT
Fugang Duan (3):
net: fec: add interrupt coalescence feature support
net:fec: increase DMA queue number
net: fec: Workaround for imx6sx enet tx hang when enable three queues
drivers/net/ethernet/freescale/fec.h | 16 +++-
drivers/net/ethernet/freescale/fec_main.c | 144 ++++++++++++++++++++++++++++--
2 files changed, 150 insertions(+), 10 deletions(-)
--
1.9.1
^ permalink raw reply
* [Patch net-next v2 2/4] net: fec: add interrupt coalescence feature support
From: Frank.Li @ 2014-09-16 17:58 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa
Cc: shawn.guo, linux-arm-kernel, Fugang Duan, Frank Li
In-Reply-To: <1410890290-11248-1-git-send-email-Frank.Li@freescale.com>
From: Fugang Duan <B38611@freescale.com>
i.MX6 SX support interrupt coalescence feature
By default, init the interrupt coalescing frame count threshold and
timer threshold.
Supply the ethtool interfaces as below for user tuning to improve
enet performance:
rx_max_coalesced_frames
rx_coalesce_usecs
tx_max_coalesced_frames
tx_coalesce_usecs
Signed-off-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec.h | 14 ++++
drivers/net/ethernet/freescale/fec_main.c | 110 ++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index b7c7722..bd70811 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -335,6 +335,14 @@ struct bufdesc_ex {
#define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII | FEC_ENET_TS_TIMER)
#define FEC_RX_DISABLED_IMASK (FEC_DEFAULT_IMASK & (~FEC_ENET_RXF))
+/* ENET interrupt coalescing macro define */
+#define FEC_ITR_CLK_SEL (0x1 << 30)
+#define FEC_ITR_EN (0x1 << 31)
+#define FEC_ITR_ICFT(X) ((X & 0xFF) << 20)
+#define FEC_ITR_ICTT(X) ((X) & 0xFFFF)
+#define FEC_ITR_ICFT_DEFAULT 200 /* Set 200 frame count threshold */
+#define FEC_ITR_ICTT_DEFAULT 1000 /* Set 1000us timer threshold */
+
#define FEC_VLAN_TAG_LEN 0x04
#define FEC_ETHTYPE_LEN 0x02
@@ -446,6 +454,12 @@ struct fec_enet_private {
unsigned int tx_align;
unsigned int rx_align;
+
+ /* hw interrupt coalesce */
+ unsigned int rx_pkts_itr;
+ unsigned int rx_time_itr;
+ unsigned int tx_pkts_itr;
+ unsigned int tx_time_itr;
};
void fec_ptp_init(struct platform_device *pdev);
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d209d2e..3a735ef 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -63,6 +63,7 @@
#include "fec.h"
static void set_multicast_list(struct net_device *ndev);
+static void fec_enet_itr_coal_init(struct net_device *ndev);
#define DRIVER_NAME "fec"
@@ -1095,6 +1096,10 @@ fec_restart(struct net_device *ndev)
/* Enable interrupts we wish to service */
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* Init the interrupt coalescing */
+ fec_enet_itr_coal_init(ndev);
+
}
static void
@@ -2234,12 +2239,117 @@ static int fec_enet_nway_reset(struct net_device *dev)
return genphy_restart_aneg(phydev);
}
+/* ITR clock source is enet system clock (clk_ahb).
+ * TCTT unit is cycle_ns * 64 cycle
+ * So, the ICTT value = X us / (cycle_ns * 64)
+ */
+static int fec_enet_us_to_itr_clock(struct net_device *ndev, int us)
+{
+ struct fec_enet_private *fep = netdev_priv(ndev);
+
+ return us * (clk_get_rate(fep->clk_ahb) / 64000) / 1000;
+}
+
+/* Set threshold for interrupt coalescing */
+static void fec_enet_itr_coal_set(struct net_device *ndev)
+{
+ struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
+ int rx_itr, tx_itr;
+
+ if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ return;
+
+ /* Must be greater than zero to avoid unpredictable behavior */
+ if (!fep->rx_time_itr || !fep->rx_pkts_itr ||
+ !fep->tx_time_itr || !fep->tx_pkts_itr)
+ return;
+
+ /* Select enet system clock as Interrupt Coalescing
+ * timer Clock Source
+ */
+ rx_itr = FEC_ITR_CLK_SEL;
+ tx_itr = FEC_ITR_CLK_SEL;
+
+ /* set ICFT and ICTT */
+ rx_itr |= FEC_ITR_ICFT(fep->rx_pkts_itr);
+ rx_itr |= FEC_ITR_ICTT(fec_enet_us_to_itr_clock(ndev, fep->rx_time_itr));
+ tx_itr |= FEC_ITR_ICFT(fep->tx_pkts_itr);
+ tx_itr |= FEC_ITR_ICTT(fec_enet_us_to_itr_clock(ndev, fep->tx_time_itr));
+
+ rx_itr |= FEC_ITR_EN;
+ tx_itr |= FEC_ITR_EN;
+
+ writel(tx_itr, fep->hwp + FEC_TXIC0);
+ writel(rx_itr, fep->hwp + FEC_RXIC0);
+ writel(tx_itr, fep->hwp + FEC_TXIC1);
+ writel(rx_itr, fep->hwp + FEC_RXIC1);
+ writel(tx_itr, fep->hwp + FEC_TXIC2);
+ writel(rx_itr, fep->hwp + FEC_RXIC2);
+}
+
+static int
+fec_enet_get_coalesce(struct net_device *ndev, struct ethtool_coalesce *ec)
+{
+ struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
+
+ if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ return -EOPNOTSUPP;
+
+ ec->rx_coalesce_usecs = fep->rx_time_itr;
+ ec->rx_max_coalesced_frames = fep->rx_pkts_itr;
+
+ ec->tx_coalesce_usecs = fep->tx_time_itr;
+ ec->tx_max_coalesced_frames = fep->tx_pkts_itr;
+
+ return 0;
+}
+
+static int
+fec_enet_set_coalesce(struct net_device *ndev, struct ethtool_coalesce *ec)
+{
+ struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
+
+ if (!(id_entry->driver_data & FEC_QUIRK_HAS_AVB))
+ return -EOPNOTSUPP;
+
+ fep->rx_time_itr = ec->rx_coalesce_usecs;
+ fep->rx_pkts_itr = ec->rx_max_coalesced_frames;
+
+ fep->tx_time_itr = ec->tx_coalesce_usecs;
+ fep->tx_pkts_itr = ec->tx_max_coalesced_frames;
+
+ fec_enet_itr_coal_set(ndev);
+
+ return 0;
+}
+
+static void fec_enet_itr_coal_init(struct net_device *ndev)
+{
+ struct ethtool_coalesce ec;
+
+ ec.rx_coalesce_usecs = FEC_ITR_ICTT_DEFAULT;
+ ec.rx_max_coalesced_frames = FEC_ITR_ICFT_DEFAULT;
+
+ ec.tx_coalesce_usecs = FEC_ITR_ICTT_DEFAULT;
+ ec.tx_max_coalesced_frames = FEC_ITR_ICFT_DEFAULT;
+
+ fec_enet_set_coalesce(ndev, &ec);
+}
+
static const struct ethtool_ops fec_enet_ethtool_ops = {
.get_settings = fec_enet_get_settings,
.set_settings = fec_enet_set_settings,
.get_drvinfo = fec_enet_get_drvinfo,
.nway_reset = fec_enet_nway_reset,
.get_link = ethtool_op_get_link,
+ .get_coalesce = fec_enet_get_coalesce,
+ .set_coalesce = fec_enet_set_coalesce,
#ifndef CONFIG_M5272
.get_pauseparam = fec_enet_get_pauseparam,
.set_pauseparam = fec_enet_set_pauseparam,
--
1.9.1
^ permalink raw reply related
* [Patch net-next v2 3/4] net:fec: increase DMA queue number
From: Frank.Li @ 2014-09-16 17:58 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa
Cc: shawn.guo, linux-arm-kernel, Fugang Duan, Frank Li
In-Reply-To: <1410890290-11248-1-git-send-email-Frank.Li@freescale.com>
From: Fugang Duan <B38611@freescale.com>
when enable interrupt coalesce, 8 BD is not enough.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index bd70811..2814610 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -296,7 +296,7 @@ struct bufdesc_ex {
* the skbuffer directly.
*/
-#define FEC_ENET_RX_PAGES 8
+#define FEC_ENET_RX_PAGES 256
#define FEC_ENET_RX_FRSIZE 2048
#define FEC_ENET_RX_FRPPG (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
#define RX_RING_SIZE (FEC_ENET_RX_FRPPG * FEC_ENET_RX_PAGES)
--
1.9.1
^ permalink raw reply related
* [Patch net-next v2 4/4] net: fec: Workaround for imx6sx enet tx hang when enable three queues
From: Frank.Li @ 2014-09-16 17:58 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa
Cc: shawn.guo, linux-arm-kernel, Fugang Duan, Frank Li
In-Reply-To: <1410890290-11248-1-git-send-email-Frank.Li@freescale.com>
From: Fugang Duan <B38611@freescale.com>
When enable three queues on imx6sx enet, and then do tx performance
test with iperf tool, after some time running, tx hang.
Found that:
If uDMA is running, software set TDAR may cause tx hang.
If uDMA is in idle, software set TDAR don't cause tx hang.
There is a TDAR race condition for mutliQ when the software sets TDAR
and the UDMA clears TDAR simultaneously or in a small window (2-4 cycles).
This will cause the udma_tx and udma_tx_arbiter state machines to hang.
The issue exist at i.MX6SX enet IP.
So, the Workaround is checking TDAR status four time, if TDAR cleared by
hardware and then write TDAR, otherwise don't set TDAR.
The patch is only one Workaround for the issue TKT210582.
Signed-off-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 3a735ef..cc8c934 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -111,6 +111,12 @@ static void fec_enet_itr_coal_init(struct net_device *ndev);
* independent rings
*/
#define FEC_QUIRK_HAS_AVB (1 << 8)
+/* There is a TDAR race condition for mutliQ when the software sets TDAR
+ * and the UDMA clears TDAR simultaneously or in a small window (2-4 cycles).
+ * This will cause the udma_tx and udma_tx_arbiter state machines to hang.
+ * The issue exist at i.MX6SX enet IP.
+ */
+#define FEC_QUIRK_ERR007885 (1 << 9)
static struct platform_device_id fec_devtype[] = {
{
@@ -139,7 +145,7 @@ static struct platform_device_id fec_devtype[] = {
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR006358 |
- FEC_QUIRK_HAS_AVB,
+ FEC_QUIRK_HAS_AVB | FEC_QUIRK_ERR007885,
}, {
/* sentinel */
}
@@ -709,6 +715,8 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
struct tso_t tso;
unsigned int index = 0;
int ret;
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
if (tso_count_descs(skb) >= fec_enet_get_free_txdesc_num(fep, txq)) {
dev_kfree_skb_any(skb);
@@ -770,7 +778,12 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
txq->cur_tx = bdp;
/* Trigger transmission start */
- writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue));
+ if (!(id_entry->driver_data & FEC_QUIRK_ERR007885) ||
+ !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
+ !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
+ !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
+ !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)))
+ writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue));
return 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv4 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: David Miller @ 2014-09-16 19:10 UTC (permalink / raw)
To: david.stevens; +Cc: netdev
In-Reply-To: <541886B9.3010206@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Tue, 16 Sep 2014 14:51:37 -0400
> So, it's incorrect. I'll fix and repost; please don't apply these
> yet.
Ok, thanks for the heads up.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Or Gerlitz @ 2014-09-16 19:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: Jesse Gross, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx-B-25-nS1pVgeCiuykdFydCiay0QCwiE75P37Q3ODRCQ@mail.gmail.com>
On Tue, Sep 16, 2014 at 9:34 PM, Tom Herbert <therbert@google.com> wrote:
> On Tue, Sep 16, 2014 at 5:44 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Tue, Sep 16, 2014 at 1:44 AM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>>
>>>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>>>> encapsulation over UDP, not VXLAN.
>>>> If the NIC implements things properly following the generic interface then I believe it should work
>>>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>>>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>>>> This presumes that any encapsulation headers doesn't require any per
>>>> segment update (so no GRE csum for instance). The stack will set up
>>>> inner headers as needed, which should enough to provide to devices the
>>>> offsets inner IP and TCP header which are needed for the the TSO
>>>> operation (outer IP and UDP can be deduced also).
>>
>>
>>
>>> From the NICs that I am familiar with this is mostly true. The main
>>> part that is missing from the current implementation is a length
>>> limit: just because the hardware can skip over headers to an offset
>>> doesn't mean that it can do so to an arbitrary depth. For example, in
>>> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
>>> probably assume that this is limited to 8 bytes. With the Intel NICs
>>> that were just announced with Geneve support, this limit has been
>>> increased to 64. If we add a parameter to the driver interface to
>>> expose this then it should be generic across tunnels.
>>
>> I'm not sure to see why the length limit became our primary concern here...
> Like Jesse mentioned above, looks like some NICs may have assumed all
> encapsulation headers are eight bytes (which allows HW to implement
> everything in fixed offsets). But this length is not a universal
> constant: FOU is zero length encapsulation headers, GUE or geneve is
> variable. The driver should really be checking if NIC can handle the
> length and if it can't perform GSO in software-- I don't think we'll
> need to expose this in the features.
I understand that for some NICs there's a claim saying the essence of
the limitation lies in an assumption on fixed length of the
encapsulation headers -- and BTW for VXLAN it's 50 (= 14 + 20 + 8 +
8) bytes, not eight. So newer NICs or new brands of existing NICs
should be more flexible.
If I correctly read your comment "The driver should really be checking
if NIC can handle the length and if it can't perform GSO in software"
as saying that a SW GSO call should be made from within the driver
when they can't serve GSO under some encap scheme -- I don't think
this is the correct track, the driver should advertize up what they
can do in HW so the stack does in SW what's not supported.
Another clarification - so FOU doesn't supersedes GUE? what's their
difference...?
Or.
^ permalink raw reply
* Re: [PATCH v12 net-next 03/11] bpf: add lookup/update/delete/iterate methods to BPF maps
From: David Miller @ 2014-09-16 19:16 UTC (permalink / raw)
To: ast
Cc: mingo, torvalds, luto, dborkman, hannes, chema, edumazet,
a.p.zijlstra, pablo, hpa, akpm, keescook, linux-api, netdev,
linux-kernel
In-Reply-To: <1410808721-27493-4-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Mon, 15 Sep 2014 12:18:33 -0700
> @@ -83,6 +112,15 @@ union bpf_attr {
> __u32 value_size; /* size of value in bytes */
> __u32 max_entries; /* max number of entries in a map */
> };
> +
> + struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
> + int map_fd;
> + void __user *key;
> + union {
> + void __user *value;
> + void __user *next_key;
> + };
> + };
> };
>
> #endif /* _UAPI__LINUX_BPF_H__ */
Depending upon the processor ABI, this change can increase the
alignment requirements of union bpf_attr. So the structure is not
compatible between patch #1 and patch #3 here.
Also, you haven't implemented any compat layer whatsoever for the
necessary translations. This happens because you are using pointers
which are different sized between 32-bit and 64-bit ABIs.
I would suggest you use instead something like "aligned_u64" since
these are just arbitrary userland cookies and using "aligned_u64"
vs. "u64" will make it so that you don't have to deal with the 64-bit
type alignment differences between x86-32 and x86-64 while writing the
compat wrappers (if any).
^ permalink raw reply
* Re: [PATCH v12 net-next 04/11] bpf: expand BPF syscall with program load/unload
From: David Miller @ 2014-09-16 19:17 UTC (permalink / raw)
To: ast
Cc: mingo, torvalds, luto, dborkman, hannes, chema, edumazet,
a.p.zijlstra, pablo, hpa, akpm, keescook, linux-api, netdev,
linux-kernel
In-Reply-To: <1410808721-27493-5-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Mon, 15 Sep 2014 12:18:34 -0700
> @@ -121,6 +132,21 @@ union bpf_attr {
> void __user *next_key;
> };
> };
> +
> + struct { /* anonymous struct used by BPF_PROG_LOAD command */
> + __u32 prog_type; /* one of enum bpf_prog_type */
> + __u32 insn_cnt;
> + const struct bpf_insn __user *insns;
> + const char __user *license;
> + };
> +};
Again, these need syscall compat handling. You may want to redesign
the types so that perhaps no compat layer translations will be needed.
^ permalink raw reply
* Re: [Patch net-next v2] net_sched: fix memory leak in cls_tcindex
From: David Miller @ 2014-09-16 19:19 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, john.fastabend
In-Reply-To: <1410824623-27516-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 15 Sep 2014 16:43:42 -0700
> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a null pointer dereference in tcindex_set_parms()
From: David Miller @ 2014-09-16 19:20 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, john.fastabend
In-Reply-To: <1410824623-27516-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 15 Sep 2014 16:43:43 -0700
> This patch fixes the following crash:
...
> 'p->h' could be NULL while 'cp->h' is always update to date.
>
> Fixes: commit 331b72922c5f58d48fd ("net: sched: RCU cls_tcindex")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Also applied, thanks Cong.
^ permalink raw reply
* [PATCH net-next] sparc: bpf_jit: add SKF_AD_PKTTYPE support to JIT
From: Alexei Starovoitov @ 2014-09-16 19:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Daniel Borkmann, Hannes Frederic Sowa, netdev
commit 233577a22089 ("net: filter: constify detection of pkt_type_offset")
allows us to implement simple PKTTYPE support in sparc JIT
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
arch/sparc/net/bpf_jit_comp.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index b2ad9dc5425e..2dde48bdcc42 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -579,16 +579,11 @@ void bpf_jit_compile(struct bpf_prog *fp)
case BPF_ANC | SKF_AD_PROTOCOL:
emit_skb_load16(protocol, r_A);
break;
-#if 0
- /* GCC won't let us take the address of
- * a bit field even though we very much
- * know what we are doing here.
- */
case BPF_ANC | SKF_AD_PKTTYPE:
- __emit_skb_load8(pkt_type, r_A);
+ __emit_skb_load8(__pkt_type_offset, r_A);
+ emit_andi(r_A, PKT_TYPE_MAX, r_A);
emit_alu_K(SRL, 5);
break;
-#endif
case BPF_ANC | SKF_AD_IFINDEX:
emit_skb_loadptr(dev, r_A);
emit_cmpi(r_A, 0);
--
1.7.9.5
^ permalink raw reply related
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