* [PATCH net-next] openvswitch: Only set TUNNEL_VXLAN_OPT if VXLAN-GBP metadata is set
From: Thomas Graf @ 2015-02-09 15:56 UTC (permalink / raw)
To: davem; +Cc: netdev, pshelar
This avoids setting TUNNEL_VXLAN_OPT for VXLAN frames which don't
have any GBP metadata set. It is not invalid to set it but unnecessary.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/openvswitch/vport-vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index ff07d40..3277a75 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c
@@ -76,7 +76,7 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff *skb,
flags = TUNNEL_KEY | (udp_hdr(skb)->check != 0 ? TUNNEL_CSUM : 0);
vxlan_port = vxlan_vport(vport);
- if (vxlan_port->exts & VXLAN_F_GBP)
+ if (vxlan_port->exts & VXLAN_F_GBP && md->gbp)
flags |= TUNNEL_VXLAN_OPT;
/* Save outer tunnel values */
--
1.9.3
^ permalink raw reply related
* Re: [RFC PATCH 00/29] net: VRF support
From: roopa @ 2015-02-09 15:54 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: David Ahern, netdev, ebiederm, Dinesh Dutt, Vipin Kumar,
Nicolas Dichtel, hannes, Eyal Birger
In-Reply-To: <20150206081046.415c3d50@halley>
On 2/5/15, 10:10 PM, Shmulik Ladkani wrote:
> On Thu, 05 Feb 2015 15:12:57 -0800 roopa <roopa@cumulusnetworks.com> wrote:
>> We have been playing with ip rules to implement vrfs. And the blocker
>> today is that we cannot bind a socket to a vrf (routing tables in this
>> case).
> Hi Roopa,
>
> One option would be using SO_MARK sockopt on that socket, and have an ip
> rule which matches this mark to point to your table.
> I don't know your exact use-cases, but you can play around with that
> idea.
sorry for getting back late on this,
yes, SO_MARK and 'ip rule fwmark' is an option to bind tx from a socket
to a table. But, There are more things that will be needed on the rx side.
and at this point we are not considering netfilter marking of the
ingress packets so
haven't been following this option
Thanks.
^ permalink raw reply
* Re: Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)
From: Neal Cardwell @ 2015-02-09 15:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Avery Fay, Netdev
In-Reply-To: <CADVnQyn20vWgfujSRRc+thud75hz0c1HG+vFEPhAu24c4-KivA@mail.gmail.com>
On Fri, Feb 6, 2015 at 4:16 PM, Neal Cardwell <ncardwell@google.com> wrote:
> On Thu, Feb 5, 2015 at 7:17 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Thu, 2015-02-05 at 15:25 -0800, Avery Fay wrote:
>>
>>> Are these available anywhere? Or could they be made available? This
>>> seems like a much better solution than disabling timestamps.
These are now in the "net-next" tree:
f06535c Merge branch 'tcp_ack_loops'
4fb17a6 tcp: mitigate ACK loops for connections as tcp_timewait_sock
f2b2c58 tcp: mitigate ACK loops for connections as tcp_sock
a9b2c06 tcp: mitigate ACK loops for connections as tcp_request_sock
032ee42 tcp: helpers to mitigate ACK loops by rate-limiting
out-of-window dupacks
neal
^ permalink raw reply
* Re: nft hash set expansion problem
From: Josh Hunt @ 2015-02-09 15:28 UTC (permalink / raw)
To: Thomas Graf
Cc: Daniel Borkmann, Pablo Neira Ayuso, kaber, netdev,
netfilter-devel
In-Reply-To: <20150209152127.GA29739@casper.infradead.org>
On 02/09/2015 09:21 AM, Thomas Graf wrote:
> On 02/09/15 at 08:44am, Josh Hunt wrote:
>> On 02/08/2015 04:43 PM, Daniel Borkmann wrote:
>>> This seems not correct as we want to have an upper limit for
>>> rhashtable expansions. It's better to define a max_shift for
>>> nftables, instead.
>>
>> Thanks Daniel that's what I wanted to know. I'll fix this on the nft_hash
>> side.
>
> I agree it does not make sense to allow unlimited growth.
> Can you enforce a max_shift > 0 in rhashtable_init() while you
> are at it?
>
Yeah I'll do that as well.
^ permalink raw reply
* Re: nft hash set expansion problem
From: Thomas Graf @ 2015-02-09 15:21 UTC (permalink / raw)
To: Josh Hunt
Cc: Daniel Borkmann, Pablo Neira Ayuso, kaber, netdev,
netfilter-devel
In-Reply-To: <54D8C7D0.9030803@akamai.com>
On 02/09/15 at 08:44am, Josh Hunt wrote:
> On 02/08/2015 04:43 PM, Daniel Borkmann wrote:
> >This seems not correct as we want to have an upper limit for
> >rhashtable expansions. It's better to define a max_shift for
> >nftables, instead.
>
> Thanks Daniel that's what I wanted to know. I'll fix this on the nft_hash
> side.
I agree it does not make sense to allow unlimited growth.
Can you enforce a max_shift > 0 in rhashtable_init() while you
are at it?
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-09 15:11 UTC (permalink / raw)
To: Michal Kazior
Cc: Neal Cardwell, linux-wireless, Network Development, Eyal Perry
In-Reply-To: <CA+BoTQn3KRym0qCJ+fLav5LQgjfiN_-Eqz0xPSc2eXJ-ijNjQw@mail.gmail.com>
On Mon, 2015-02-09 at 14:47 +0100, Michal Kazior wrote:
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 65caf8b..5e249bf 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1996,6 +1996,7 @@ static bool tcp_write_xmit(struct sock *sk,
> unsigned int mss_now, int nonagle,
> max_segs = tcp_tso_autosize(sk, mss_now);
> while ((skb = tcp_send_head(sk))) {
> unsigned int limit;
> + unsigned int amount;
>
> tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
> BUG_ON(!tso_segs);
> @@ -2053,7 +2054,9 @@ static bool tcp_write_xmit(struct sock *sk,
> unsigned int mss_now, int nonagle,
> * of queued bytes to ensure line rate.
> * One example is wifi aggregation (802.11 AMPDU)
> */
> - limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
> + amount = sk->sk_tx_completion_delay_us *
> + (sk->sk_pacing_rate >> 10);
> + limit = max(2 * skb->truesize, amount >> 10);
> limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
>
> if (atomic_read(&sk->sk_wmem_alloc) > limit) {
This is not what I suggested.
If you test this on any other network device, you'll have
sk->sk_tx_completion_delay_us == 0
amount = 0 * (sk->sk_pacing_rate >> 10); --> 0
limit = max(2 * skb->truesize, amount >> 10); --> 2 * skb->truesize
So non TSO/GSO NIC will not be able to queue more than 2 MSS (one MSS
per skb)
Then if you store only the last tx completion, you have the possibility
of having a last packet of a train (say a retransmit) to make it very
low.
Ideally the formula would be in TCP something very fast to compute :
amount = (sk->sk_pacing_rate >> 10) + sk->tx_completion_delay_cushion;
limit = max(2 * skb->truesize, amount);
limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
So a 'problematic' driver would have to do the math (64 bit maths) like
this :
sk->tx_completion_delay_cushion = ewma_tx_delay * sk->sk_pacing_rate;
^ permalink raw reply
* Re: nft hash set expansion problem
From: Josh Hunt @ 2015-02-09 14:44 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Thomas Graf, Pablo Neira Ayuso, kaber, netdev, netfilter-devel
In-Reply-To: <54D7E677.5050708@iogearbox.net>
On 02/08/2015 04:43 PM, Daniel Borkmann wrote:
> On 02/08/2015 08:38 PM, Josh Hunt wrote:
>> Nft hash sets are unable to expand past the initial # of buckets. This
>> is b/c nft hash sets don't define the max_shift parameter and so
>> rht_grow_above_75():
> ...
>> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
>> index e96fc00..2c51617 100644
>> --- a/lib/rhashtable.c
>> +++ b/lib/rhashtable.c
>> @@ -250,7 +250,7 @@ bool rht_grow_above_75(const struct rhashtable
>> *ht, size_t new_size)
>> {
>> /* Expand table when exceeding 75% load */
>> return atomic_read(&ht->nelems) > (new_size / 4 * 3) &&
>> - (ht->p.max_shift && atomic_read(&ht->shift) <
>> ht->p.max_shift);
>> + (ht->p.max_shift ? atomic_read(&ht->shift) <
>> ht->p.max_shift : 1);
>> }
>> EXPORT_SYMBOL_GPL(rht_grow_above_75);
>
> This seems not correct as we want to have an upper limit for
> rhashtable expansions. It's better to define a max_shift for
> nftables, instead.
Thanks Daniel that's what I wanted to know. I'll fix this on the
nft_hash side.
Josh
^ permalink raw reply
* [PATCH v2 2/2] ipv6: Make __ipv6_select_ident static
From: Vladislav Yasevich @ 2015-02-09 14:38 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Vladislav Yasevich
In-Reply-To: <1423492701-21429-1-git-send-email-vyasevic@redhat.com>
Make __ipv6_select_ident() static as it isn't used outside
the file.
Fixes: 0508c07f5e0c9 (ipv6: Select fragment id during UFO segmentation if not set.)
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
include/net/ipv6.h | 2 --
net/ipv6/output_core.c | 3 ++-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 6e416f6..fde3b59 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -671,8 +671,6 @@ static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_add
return __ipv6_addr_diff(a1, a2, sizeof(struct in6_addr));
}
-u32 __ipv6_select_ident(u32 hashrnd, struct in6_addr *dst,
- struct in6_addr *src);
void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
void ipv6_proxy_select_ident(struct sk_buff *skb);
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index a86cf60..74581f7 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -9,7 +9,8 @@
#include <net/addrconf.h>
#include <net/secure_seq.h>
-u32 __ipv6_select_ident(u32 hashrnd, struct in6_addr *dst, struct in6_addr *src)
+static u32 __ipv6_select_ident(u32 hashrnd, struct in6_addr *dst,
+ struct in6_addr *src)
{
u32 hash, id;
--
1.9.3
^ permalink raw reply related
* [PATCH v2 1/2] ipv6: Fix fragment id assignment on LE arches.
From: Vladislav Yasevich @ 2015-02-09 14:38 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Vladislav Yasevich
In-Reply-To: <1423492701-21429-1-git-send-email-vyasevic@redhat.com>
Recent commit:
0508c07f5e0c94f38afd5434e8b2a55b84553077
Author: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue Feb 3 16:36:15 2015 -0500
ipv6: Select fragment id during UFO segmentation if not set.
Introduced a bug on LE in how ipv6 fragment id is assigned.
This was cought by nightly sparce check:
Resolve the following sparce error:
net/ipv6/output_core.c:57:38: sparse: incorrect type in assignment
(different base types)
net/ipv6/output_core.c:57:38: expected restricted __be32
[usertype] ip6_frag_id
net/ipv6/output_core.c:57:38: got unsigned int [unsigned]
[assigned] [usertype] id
Fixes: 0508c07f5e0c9 (ipv6: Select fragment id during UFO segmentation if not set.)
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
net/ipv6/output_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index 54520a0..a86cf60 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -54,7 +54,7 @@ void ipv6_proxy_select_ident(struct sk_buff *skb)
id = __ipv6_select_ident(ip6_proxy_idents_hashrnd,
&addrs[1], &addrs[0]);
- skb_shinfo(skb)->ip6_frag_id = id;
+ skb_shinfo(skb)->ip6_frag_id = htonl(id);
}
EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
--
1.9.3
^ permalink raw reply related
* [PATCH v2 0/2] IPv6 Fix 2 small issues with UFO restoration code
From: Vladislav Yasevich @ 2015-02-09 14:38 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Vladislav Yasevich
This series fixes 2 small issues introduced by the
"Restore UFO support to virtio_net devices" series.
Thanks.
V2: Fixed patch title and description for patch1.
Vladislav Yasevich (2):
ipv6: Resolve sparce error with fragment id selection
ipv6: Make __ipv6_select_ident static
include/net/ipv6.h | 2 --
net/ipv6/output_core.c | 5 +++--
2 files changed, 3 insertions(+), 4 deletions(-)
--
1.9.3
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: Kristian Evensen @ 2015-02-09 14:30 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Network Development, Aleksander Morgado
In-Reply-To: <8761bbqker.fsf@nemi.mork.no>
On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@mork.no> wrote:
> That is pretty old relative to this hardware. First commercial release?
> I don't really want to push you to do an upgrade, but it would sure be
> nice to have this test repeated on a recent firmware version. Not that
> I can spot anything particularily promising in the release notes.
I updated firmware now, but still see the same behavior.
> I did find our previous discussions about these two RMNET1 and RMNET2
> functions, e.g:
> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
> and it seems to indicate that both work as long as you configure them
> for 802.3 framing. But that could just be an information feedback
> loop...
That is correct. In order for this device to accept network traffic
(or driver to accept packets from device), I have to set the transfer
mode to 802.3.
-Kristian
^ permalink raw reply
* Re: [PATCH v3 12/18] crypto: switch af_alg_make_sg() to iov_iter
From: Stephan Mueller @ 2015-02-09 13:59 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev, linux-crypto
In-Reply-To: <1423032009-18367-12-git-send-email-viro@ZenIV.linux.org.uk>
Am Mittwoch, 4. Februar 2015, 06:40:03 schrieb Al Viro:
Hi Al,
> From: Al Viro <viro@zeniv.linux.org.uk>
>
> With that, all ->sendmsg() instances are converted to iov_iter primitives
> and are agnostic wrt the kind of iov_iter they are working with.
> So's the last remaining ->recvmsg() instance that wasn't kind-agnostic yet.
> All ->sendmsg() and ->recvmsg() advance ->msg_iter by the amount actually
> copied and none of them modifies the underlying iovec, etc.
After testing this patch with the test application by simply executing
[1]/test/test.sh, the hash and skcipher interface invocation hang in kernel
space. Though, I am not sure where the problem is.
For individual invocations of the tests, you may look into [1]/test/kcapi-
main.c in the comments above cavs_sym or cavs_hash.
[1] http://www.chronox.de/libkcapi.html
--
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 3/3][v2] mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
From: Alexandre Courbot @ 2015-02-09 13:53 UTC (permalink / raw)
To: Rojhalat Ibrahim
Cc: linux-gpio@vger.kernel.org, Alexandre Courbot, Linus Walleij,
David Miller, netdev
In-Reply-To: <2302857.SIRJpJWX1o@pcimr>
On Mon, Feb 9, 2015 at 6:14 PM, Rojhalat Ibrahim <imr@rtschenk.de> wrote:
> On Monday 09 February 2015 14:18:14 Alexandre Courbot wrote:
>> On Thu, Jan 22, 2015 at 1:46 AM, Rojhalat Ibrahim <imr@rtschenk.de> wrote:
>> > Use the new gpiod_get_array and gpiod_put_array functions for obtaining and
>> > disposing of GPIO descriptors.
>> >
>> > Cc: David Miller <davem@davemloft.net>
>> > Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
>> > ---
>> > This patch depends on my previous patch "gpiolib: add gpiod_get_array and
>> > gpiod_put_array functions".
>> >
>> > v2: use the new interface
>> >
>> > Only compile-tested.
>> >
>> > drivers/net/phy/mdio-mux-gpio.c | 61 +++++++++++-----------------------------
>> > 1 file changed, 18 insertions(+), 43 deletions(-)
>>
>> Oh yeah.
>>
>> It would be great to have a tested-by for the next revision though.
>>
>> Rojhalat, have you been able to test these new interfaces outside of
>> this driver?
>>
>
> I have tested the new interface with my FPGA configuration driver (which I
> plan to submit eventually). I cannot test the mdio-mux-gpio driver because
> I lack the necessary hardware.
That's good enough - I just want to make sure the interface has
undergone some testing. :P
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-09 13:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: Neal Cardwell, linux-wireless, Network Development, Eyal Perry
In-Reply-To: <CA+BoTQkazCOin7VWLfrHUjtgKDPV6T+sFsk5FPS7D-morr4FZQ@mail.gmail.com>
On 6 February 2015 at 15:09, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 6 February 2015 at 14:53, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Fri, 2015-02-06 at 05:40 -0800, Eric Dumazet wrote:
>>
>>> tcp_wfree() could maintain in tp->tx_completion_delay_ms an EWMA
>>> of TX completion delay. But this would require yet another expensive
>>> call to ktime_get() if HZ < 1000.
>>>
>>> Then tcp_write_xmit() could use it to adjust :
>>>
>>> limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 9);
>>>
>>> to
>>>
>>> amount = (2 + tp->tx_completion_delay_ms) * sk->sk_pacing_rate
>>>
>>> limit = max(2 * skb->truesize, amount / 1000);
>>>
>>> I'll cook a patch.
>>
>> Hmm... doing this in all protocols would be too expensive,
>> and we do not want to include time spent in qdiscs.
>>
>> wifi could eventually do that, providing in skb->tx_completion_delay_us
>> the time spent in wifi driver.
>>
>> This way, we would have no penalty for network devices doing normal skb
>> orphaning (loopback interface, ethernet, ...)
>
> I'll play around with this idea and report back later.
I'm able to get 600mbps with 5 flows and 250mbps with 1 flow, i.e.
same as before the regression. I'm attaching the patch at the end of
my mail - is this approach viable?
I wonder if there's anything that can be done to allow 600mbps (line
rate) on 1 flow with ath10k without tweaking tcp_limit_output_bytes
(you can't expect end-users to tweak this).
Perhaps tcp_limit_output_bytes should also consider tx_completion_delay, e.g.:
amount = sk->sk_tx_completion_delay_us;
amount *= sk->sk_pacing_rate >> 10;
limit = max(2 * skb->truesize, amount >> 10);
max_limit = sysctl_tcp_limit_output_bytes;
max_limit *= 1 + (sk->sk_tx_completion_delay_us / USEC_PER_MSEC);
limit = min(u32, limit, max_limit);
With this I get ~400mbps on 1 flow. If I add the original 1ms extra
delay from your formula to tx_completion_delay I fill in ath10k I get
nearly line rate in 1 flow (almost 600mbps; it hops between 570-620).
Decreasing tcp_limit_output_bytes decreases throughput (e.g. 64K gives
300mbps, 32K gives 180mbps, 16K gives 110mbps). Multiple flows in
iperf seem unbalanced with 128K limit, but look okay with 32K).
Michał
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 3be3a59..4ff0ae8 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -82,6 +82,7 @@ struct ath10k_skb_cb {
dma_addr_t paddr;
u8 eid;
u8 vdev_id;
+ ktime_t stamp;
struct {
u8 tid;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 15e47f4..5efb2a7 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2620,6 +2620,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
if (info->flags & IEEE80211_TX_CTL_NO_CCK_RATE)
ath10k_dbg(ar, ATH10K_DBG_MAC,
"IEEE80211_TX_CTL_NO_CCK_RATE\n");
+ ATH10K_SKB_CB(skb)->stamp = ktime_get();
ATH10K_SKB_CB(skb)->htt.is_offchan = false;
ATH10K_SKB_CB(skb)->htt.tid = ath10k_tx_h_get_tid(hdr);
ATH10K_SKB_CB(skb)->vdev_id = ath10k_tx_h_get_vdev_id(ar, vif);
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
index 3f00cec..0d5539b 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -15,6 +15,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <net/sock.h>
#include "core.h"
#include "txrx.h"
#include "htt.h"
@@ -82,6 +83,13 @@ void ath10k_txrx_tx_unref(struct ath10k_htt *htt,
ath10k_report_offchan_tx(htt->ar, msdu);
+ if (msdu->sk) {
+ ACCESS_ONCE(msdu->sk->sk_tx_completion_delay_us) =
+ ktime_to_ns(ktime_sub(ktime_get(),
+ skb_cb->stamp)) /
+ NSEC_PER_USEC;
+ }
+
info = IEEE80211_SKB_CB(msdu);
memset(&info->status, 0, sizeof(info->status));
trace_ath10k_txrx_tx_unref(ar, tx_done->msdu_id);
diff --git a/include/net/sock.h b/include/net/sock.h
index 2210fec..6b15d71 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -390,6 +390,7 @@ struct sock {
int sk_wmem_queued;
gfp_t sk_allocation;
u32 sk_pacing_rate; /* bytes per second */
+ u32 sk_tx_completion_delay_us;
u32 sk_max_pacing_rate;
netdev_features_t sk_route_caps;
netdev_features_t sk_route_nocaps;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 65caf8b..5e249bf 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1996,6 +1996,7 @@ static bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
max_segs = tcp_tso_autosize(sk, mss_now);
while ((skb = tcp_send_head(sk))) {
unsigned int limit;
+ unsigned int amount;
tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
BUG_ON(!tso_segs);
@@ -2053,7 +2054,9 @@ static bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
* of queued bytes to ensure line rate.
* One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ amount = sk->sk_tx_completion_delay_us *
+ (sk->sk_pacing_rate >> 10);
+ limit = max(2 * skb->truesize, amount >> 10);
limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
if (atomic_read(&sk->sk_wmem_alloc) > limit) {
^ permalink raw reply related
* Re: [PATCH v3 12/18] crypto: switch af_alg_make_sg() to iov_iter
From: Stephan Mueller @ 2015-02-09 13:33 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev, linux-crypto
In-Reply-To: <1423032009-18367-12-git-send-email-viro@ZenIV.linux.org.uk>
Am Mittwoch, 4. Februar 2015, 06:40:03 schrieb Al Viro:
Hi Al,
> From: Al Viro <viro@zeniv.linux.org.uk>
>
> With that, all ->sendmsg() instances are converted to iov_iter primitives
> and are agnostic wrt the kind of iov_iter they are working with.
> So's the last remaining ->recvmsg() instance that wasn't kind-agnostic yet.
> All ->sendmsg() and ->recvmsg() advance ->msg_iter by the amount actually
> copied and none of them modifies the underlying iovec, etc.
>
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> crypto/af_alg.c | 40 ++++++++------------------
> crypto/algif_hash.c | 45 ++++++++++++------------------
> crypto/algif_skcipher.c | 74
> ++++++++++++++++++++++--------------------------- include/crypto/if_alg.h |
> 3 +-
> 4 files changed, 62 insertions(+), 100 deletions(-)
>
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 4665b79c..eb78fe8 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -338,49 +338,31 @@ static const struct net_proto_family alg_family = {
> .owner = THIS_MODULE,
> };
>
> -int af_alg_make_sg(struct af_alg_sgl *sgl, void __user *addr, int len,
> - int write)
> +int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter *iter, int len)
Shouldn't len be size_t? iov_iter_get_pages wants a size_t. Also, the
invocation of af_alg_make_sg uses an unsigned variable that is provided by
userspace.
> {
> - unsigned long from = (unsigned long)addr;
> - unsigned long npages;
> - unsigned off;
> - int err;
> - int i;
> -
> - err = -EFAULT;
> - if (!access_ok(write ? VERIFY_READ : VERIFY_WRITE, addr, len))
> - goto out;
> -
> - off = from & ~PAGE_MASK;
> - npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
> - if (npages > ALG_MAX_PAGES)
> - npages = ALG_MAX_PAGES;
> + size_t off;
> + ssize_t n;
> + int npages, i;
>
> - err = get_user_pages_fast(from, npages, write, sgl->pages);
> - if (err < 0)
> - goto out;
> + n = iov_iter_get_pages(iter, sgl->pages, len, ALG_MAX_PAGES, &off);
> + if (n < 0)
> + return n;
>
> - npages = err;
> - err = -EINVAL;
> + npages = PAGE_ALIGN(off + n);
> if (WARN_ON(npages == 0))
> - goto out;
> -
> - err = 0;
> + return -EINVAL;
>
> sg_init_table(sgl->sg, npages);
>
> - for (i = 0; i < npages; i++) {
> + for (i = 0, len = n; i < npages; i++) {
> int plen = min_t(int, len, PAGE_SIZE - off);
>
> sg_set_page(sgl->sg + i, sgl->pages[i], plen, off);
>
> off = 0;
> len -= plen;
> - err += plen;
> }
> -
> -out:
> - return err;
> + return n;
> }
> EXPORT_SYMBOL_GPL(af_alg_make_sg);
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 01f56eb..01da360 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -41,8 +41,6 @@ static int hash_sendmsg(struct kiocb *unused, struct
> socket *sock, struct sock *sk = sock->sk;
> struct alg_sock *ask = alg_sk(sk);
> struct hash_ctx *ctx = ask->private;
> - unsigned long iovlen;
> - const struct iovec *iov;
> long copied = 0;
> int err;
>
> @@ -58,37 +56,28 @@ static int hash_sendmsg(struct kiocb *unused, struct
> socket *sock,
>
> ctx->more = 0;
>
> - for (iov = msg->msg_iter.iov, iovlen = msg->msg_iter.nr_segs; iovlen >
0;
> - iovlen--, iov++) {
> - unsigned long seglen = iov->iov_len;
> - char __user *from = iov->iov_base;
> + while (iov_iter_count(&msg->msg_iter)) {
> + int len = iov_iter_count(&msg->msg_iter);
size_t for len?
>
> - while (seglen) {
> - int len = min_t(unsigned long, seglen, limit);
> - int newlen;
> + if (len > limit)
> + len = limit;
If we leave int, do we have a wrap problem here?
>
> - newlen = af_alg_make_sg(&ctx->sgl, from, len, 0);
> - if (newlen < 0) {
> - err = copied ? 0 : newlen;
> - goto unlock;
> - }
> -
> - ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL,
> - newlen);
> -
> - err = af_alg_wait_for_completion(
> - crypto_ahash_update(&ctx->req),
> - &ctx->completion);
> + len = af_alg_make_sg(&ctx->sgl, &msg->msg_iter, len);
> + if (len < 0) {
> + err = copied ? 0 : len;
> + goto unlock;
> + }
>
> - af_alg_free_sg(&ctx->sgl);
> + ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL, len);
>
> - if (err)
> - goto unlock;
> + err = af_alg_wait_for_completion(crypto_ahash_update(&ctx-
>req),
> + &ctx->completion);
> + af_alg_free_sg(&ctx->sgl);
> + if (err)
> + goto unlock;
>
> - seglen -= newlen;
> - from += newlen;
> - copied += newlen;
> - }
> + copied += len;
> + iov_iter_advance(&msg->msg_iter, len);
> }
>
> err = 0;
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index c12207c..37110fd 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -426,67 +426,59 @@ static int skcipher_recvmsg(struct kiocb *unused,
> struct socket *sock, &ctx->req));
> struct skcipher_sg_list *sgl;
> struct scatterlist *sg;
> - unsigned long iovlen;
> - const struct iovec *iov;
> int err = -EAGAIN;
> int used;
> long copied = 0;
>
> lock_sock(sk);
> - for (iov = msg->msg_iter.iov, iovlen = msg->msg_iter.nr_segs; iovlen >
0;
> - iovlen--, iov++) {
> - unsigned long seglen = iov->iov_len;
> - char __user *from = iov->iov_base;
> -
> - while (seglen) {
> - sgl = list_first_entry(&ctx->tsgl,
> - struct skcipher_sg_list, list);
> - sg = sgl->sg;
> -
> - while (!sg->length)
> - sg++;
> -
> - if (!ctx->used) {
> - err = skcipher_wait_for_data(sk, flags);
> - if (err)
> - goto unlock;
> - }
> + while (iov_iter_count(&msg->msg_iter)) {
> + sgl = list_first_entry(&ctx->tsgl,
> + struct skcipher_sg_list, list);
> + sg = sgl->sg;
>
> - used = min_t(unsigned long, ctx->used, seglen);
> + while (!sg->length)
> + sg++;
>
> - used = af_alg_make_sg(&ctx->rsgl, from, used, 1);
> - err = used;
> - if (err < 0)
> + used = ctx->used;
> + if (!used) {
I do not think that this change is correct. The following
skcipher_wait_for_data puts the recvmsg to sleep. That means, ctx->used may
change due to a new sendmsg() while sleeping.
Hence, I would think that we should leave the code as it was:
if (!ctx->used)
and then in the following
> + err = skcipher_wait_for_data(sk, flags);
> + if (err)
> goto unlock;
> + }
> +
> + used = min_t(unsigned long, used, iov_iter_count(&msg-
>msg_iter));
we use ctx->used here.
And shouldn't we use size_t here instead of unsigned long?
> +
> + used = af_alg_make_sg(&ctx->rsgl, &msg->msg_iter, used);
> + err = used;
> + if (err < 0)
> + goto unlock;
>
> - if (ctx->more || used < ctx->used)
> - used -= used % bs;
> + if (ctx->more || used < ctx->used)
> + used -= used % bs;
>
> - err = -EINVAL;
> - if (!used)
> - goto free;
> + err = -EINVAL;
> + if (!used)
> + goto free;
>
> - ablkcipher_request_set_crypt(&ctx->req, sg,
> - ctx->rsgl.sg, used,
> - ctx->iv);
> + ablkcipher_request_set_crypt(&ctx->req, sg,
> + ctx->rsgl.sg, used,
> + ctx->iv);
>
> - err = af_alg_wait_for_completion(
> + err = af_alg_wait_for_completion(
> ctx->enc ?
> crypto_ablkcipher_encrypt(&ctx->req) :
> crypto_ablkcipher_decrypt(&ctx->req),
> &ctx->completion);
>
> free:
> - af_alg_free_sg(&ctx->rsgl);
> + af_alg_free_sg(&ctx->rsgl);
>
> - if (err)
> - goto unlock;
> + if (err)
> + goto unlock;
>
> - copied += used;
> - from += used;
> - seglen -= used;
> - skcipher_pull_sgl(sk, used);
> - }
> + copied += used;
> + skcipher_pull_sgl(sk, used);
> + iov_iter_advance(&msg->msg_iter, used);
> }
>
> err = 0;
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index cd62bf4..88ea64e 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -67,8 +67,7 @@ int af_alg_unregister_type(const struct af_alg_type
> *type); int af_alg_release(struct socket *sock);
> int af_alg_accept(struct sock *sk, struct socket *newsock);
>
> -int af_alg_make_sg(struct af_alg_sgl *sgl, void __user *addr, int len,
> - int write);
> +int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter *iter, int len);
> void af_alg_free_sg(struct af_alg_sgl *sgl);
>
> int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con);
--
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: Bjørn Mork @ 2015-02-09 13:33 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Network Development, Aleksander Morgado
In-Reply-To: <CAKfDRXjwsQRA+CxaUpZVoDW3TmrUd6edSf_gi1EkPMcTFv0F5A@mail.gmail.com>
Kristian Evensen <kristian.evensen@gmail.com> writes:
> On Mon, Feb 9, 2015 at 12:55 PM, Kristian Evensen
> <kristian.evensen@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>> Just to be sure: You do have a configuration where interfaces #10 and
>>> #11 are visible, but none of them respond to any QMI at all? Not even
>>> CTL SYNC? Could you get a minimal usbmon trace of that?
>
> Here is a minial usbmon where I send SYNC to interface 10. After I
> made the trace, I tried interface 8 (to make sure that there was
> nothing wrong with modem) and it worked fine. ModemManager or any
> similar tool is not running.
Thanks.
> The firmware is SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28
That is pretty old relative to this hardware. First commercial release?
I don't really want to push you to do an upgrade, but it would sure be
nice to have this test repeated on a recent firmware version. Not that
I can spot anything particularily promising in the release notes.
Did you have one of these 9x15 modems, Aleksander? Did you ever verify
whether the additional QMI interface(s) worked?
I did find our previous discussions about these two RMNET1 and RMNET2
functions, e.g:
http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
and it seems to indicate that both work as long as you configure them
for 802.3 framing. But that could just be an information feedback
loop...
> -Kristian
> ffff8800cbbad240 1429569304 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1429569566 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1429570337 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1434576966 C Ii:3:050:7 -2:256 0
> ffff8800cbbad240 1434577061 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1434577154 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1434577968 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1439584564 C Ii:3:050:7 -2:256 0
> ffff8800cbbad240 1439584687 S Ii:3:050:7 -115:256 10 <
> ffff8800cbbadb40 1439584829 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
> ffff8800cbbadb40 1439585699 C Co:3:050:0 0 12 >
> ffff8800cbbad240 1440477055 C Ii:3:050:7 -2:256 0
Hmm, it's been a long time since I've looked at one of these so I might
be wrong, but I must admit that it looks pretty dead. I assume the
ENOENT Ii callback status indicates a timeout?
Bjørn
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: Kristian Evensen @ 2015-02-09 12:26 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Network Development
In-Reply-To: <CAKfDRXhW-izhes0qq2qJA0ojm37Eg=dybYSdzo8u-VzhT15EGw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
Hi,
On Mon, Feb 9, 2015 at 12:55 PM, Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Hi,
>
> On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
>> Just to be sure: You do have a configuration where interfaces #10 and
>> #11 are visible, but none of them respond to any QMI at all? Not even
>> CTL SYNC? Could you get a minimal usbmon trace of that?
Here is a minial usbmon where I send SYNC to interface 10. After I
made the trace, I tried interface 8 (to make sure that there was
nothing wrong with modem) and it worked fine. ModemManager or any
similar tool is not running.
The firmware is SWI9X15C_05.05.02.00 r19147 carmd-fwbuild1 2013/11/15 13:54:28
-Kristian
[-- Attachment #2: mc73xx-intf-10-no-reply.log --]
[-- Type: text/x-log, Size: 747 bytes --]
ffff8800cbbad240 1429569304 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1429569566 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1429570337 C Co:3:050:0 0 12 >
ffff8800cbbad240 1434576966 C Ii:3:050:7 -2:256 0
ffff8800cbbad240 1434577061 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1434577154 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1434577968 C Co:3:050:0 0 12 >
ffff8800cbbad240 1439584564 C Ii:3:050:7 -2:256 0
ffff8800cbbad240 1439584687 S Ii:3:050:7 -115:256 10 <
ffff8800cbbadb40 1439584829 S Co:3:050:0 s 21 00 0000 000a 000c 12 = 010b0000 00000001 27000000
ffff8800cbbadb40 1439585699 C Co:3:050:0 0 12 >
ffff8800cbbad240 1440477055 C Ii:3:050:7 -2:256 0
^ permalink raw reply
* Re: Kill I4L?
From: Paul Bolle @ 2015-02-09 12:12 UTC (permalink / raw)
To: Karsten Keil
Cc: Tilman Schmidt, Joe Perches, Sergei Shtylyov, Bas Peters, isdn,
julia.lawall, davem, netdev, linux-kernel
In-Reply-To: <54D7F87E.4050506@linux-pingi.de>
On Mon, 2015-02-09 at 00:59 +0100, Karsten Keil wrote:
> Am 08.02.2015 um 20:47 schrieb Tilman Schmidt:
> > Am 07.02.2015 um 21:43 schrieb Paul Bolle:
> >> 2) Broader picture: if I remember correctly there are now four
> >> different flavors of ISDN in the kernel: - really old: pre-i4l
> >
> > I don't think any traces of that are still present in current kernel
> > releases. It should all have been left behind on the switch to 2.6.
>
> Yes.
I just refreshed my memory: drivers/isdn/hysdn predates I4L. It was
added in v2.3.45, while I4L was mainlined in v2.6.4. But, on the other
hand, one can optionally use HYSDN via "just old" CAPI.
(HYSDN looks a bit odd. By default "they register as ethernet card". I
guess this will only work if both ends of the ISDN connection have a
setup like that. But, who knows, maybe someone is still using HYSDN in
that way. www.hypercope.de serves "Sponsored Listings", by the way.)
> >> - very old: i4l - just old: CAPI - not so old: mISDN
> >
> > Those are the in-tree ones. To make matters worse, the Asterisk people
> > invented three more (Zaptel, DAHDI and vISDN) which are maintained
> > out-of-tree. Apparently they weren't satisfied with any the in-tree
> > ones and didn't feel like helping to improve one of them to match
> > their needs.
> >
> >> [snip] So the current ISDN situation is a bit messy.
> >
> > That's putting it mildly.
> >
> >> Tilman might be able to provide a clearer, and maybe less grumpy,
> >> summary of the current situation.
> >
> > Don't know about either. ;-)
Paul Bolle
^ permalink raw reply
* Re: [net-next 15/15] i40e/i40evf: Add call to u64_stats_init to init
From: Sergei Shtylyov @ 2015-02-09 12:09 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Carolyn Wyborny, netdev, nhorman, sassmann, jogreene
In-Reply-To: <1423478641-3138-16-git-send-email-jeffrey.t.kirsher@intel.com>
Hello.
On 2/9/2015 1:44 PM, Jeff Kirsher wrote:
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
> This patch adds a call to u64_stats_init to Rx setup.
> This done in order to avoid lockdep errors with seqcount on newer kernels.
> Change-ID: Ia8ba8f0bcbd1c0e926f97d70aeee4ce4fd055e93
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 ++
> drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 ++
> 2 files changed, 4 insertions(+)
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> index 5aa6ef1..f4d6d90 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> @@ -1098,6 +1098,8 @@ int i40e_setup_rx_descriptors(struct i40e_ring *rx_ring)
> if (!rx_ring->rx_bi)
> goto err;
>
> + u64_stats_init(rx_ring->syncp);
This is over-indented.
> +
> /* Round up to nearest 4K */
> rx_ring->size = ring_is_16byte_desc_enabled(rx_ring)
> ? rx_ring->count * sizeof(union i40e_16byte_rx_desc)
> diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
> index 4bf15da..459499a 100644
> --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
> +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
> @@ -596,6 +596,8 @@ int i40evf_setup_rx_descriptors(struct i40e_ring *rx_ring)
> if (!rx_ring->rx_bi)
> goto err;
>
> + u64_stats_init(rx_ring->syncp);
Likewise.
> +
> /* Round up to nearest 4K */
> rx_ring->size = ring_is_16byte_desc_enabled(rx_ring)
> ? rx_ring->count * sizeof(union i40e_16byte_rx_desc)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] stmmac: Add AXI burst length support to platform device.
From: Mark Rutland @ 2015-02-09 12:04 UTC (permalink / raw)
To: Chen Baozi
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
In-Reply-To: <1423285636-8623-4-git-send-email-cbz@baozis.org>
On Sat, Feb 07, 2015 at 05:07:16AM +0000, Chen Baozi wrote:
> The AXI Bus Mode Register controls the AXI master behavior. It is mainly
> used to control the burst splitting and the number of outstanding requests.
> This register is present and valid only in GMAC-AXI configuration. The old
> driver only supports this feature on PCI devices. This patch adds an
> 'snps,apl' properties in DT to enable it on platform devices.
>
> Signed-off-by: Chen Baozi <chenbaozi@kylinos.com.cn>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 1 +
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index c41afd9..8f3c834 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -43,6 +43,7 @@ Optional properties:
> available this clock is used for programming the Timestamp Addend Register.
> If not passed then the system clock will be used and this is fine on some
> platforms.
> +- snps,abl: AXI Burst Length
This is not a good name (though I see it follows "snps,pbl", which is
also not a good name)...
Why does this need to be in the DT? Is this required for correctness? Or
performance?
Thanks,
Mark.
>
> Examples:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 3039de2..abbc897 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -230,6 +230,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> return -ENOMEM;
> plat->dma_cfg = dma_cfg;
> of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
> + of_property_read_u32(np, "snps,abl", &dma_cfg->burst_len);
> dma_cfg->fixed_burst =
> of_property_read_bool(np, "snps,fixed-burst");
> dma_cfg->mixed_burst =
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: Kristian Evensen @ 2015-02-09 11:55 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Network Development
In-Reply-To: <87a90nqp45.fsf@nemi.mork.no>
Hi,
On Mon, Feb 9, 2015 at 12:51 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Just to be sure: You do have a configuration where interfaces #10 and
> #11 are visible, but none of them respond to any QMI at all? Not even
> CTL SYNC? Could you get a minimal usbmon trace of that?
Yes, that is correct. I will get hold of the device with the card in
it and run another test to provide the trace. The model is MC7304 btw.
Thanks for all the additional info.
-Kristian
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI
From: Bjørn Mork @ 2015-02-09 11:51 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1423477027-10869-1-git-send-email-kristian.evensen@gmail.com>
Kristian Evensen <kristian.evensen@gmail.com> writes:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> Sierra Wireless MC73xx interface 10 is not usable with QMI, as the interface
> does not respond to any QMI messages.
Really? I don't have any such devices to test with unfortunately, but
the Sierra Wireless (SWI) "USB Driver Developer's Guide - AirPrime
MC73xx" [1] claims that interfaces 8, 10 and 11 represent RMNET1, RMNET2
and RMNET3 respectively. It is confirmed [2] from SWI that RMNET3 is
non-functional, similar to the status of the MC77xx devices, but RMNET2
is believed to work. At least I believe so until you sent this patch...
Just to be sure: You do have a configuration where interfaces #10 and
#11 are visible, but none of them respond to any QMI at all? Not even
CTL SYNC? Could you get a minimal usbmon trace of that?
Note that interface #10 (RMNET2) still is enabled for 1199:68c0 in the
current (Version S2.20N2.27) out-of-tree drivers from SWI [3],
indicating that they believe it works:
#define BIT_9X15 (31)
..
static int GobiNetDriverBind(
struct usbnet * pDev,
struct usb_interface * pIntf )
{
..
/* We only accept certain interfaces */
if (pIntf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC )
{
DBG( "Ignoring non vendor class interface #%d\n",
pIntf->cur_altsetting->desc.bInterfaceNumber );
return -ENODEV;
}
else if (pDev->driver_info->data &&
!test_bit(pIntf->cur_altsetting->desc.bInterfaceNumber, &pDev->driver_info->data)) {
DBG( "invalid interface %d\n",
pIntf->cur_altsetting->desc.bInterfaceNumber );
return -ENODEV;
}
..
static const struct driver_info GobiNetInfo_9x15 = {
.description = "GobiNet Ethernet Device",
.flags = FLAG_ETHER,
.bind = GobiNetDriverBind,
.unbind = GobiNetDriverUnbind,
#ifdef DATA_MODE_RP
.rx_fixup = GobiNetDriverRxFixup,
.tx_fixup = GobiNetDriverTxFixup,
#elif defined(QOS_MODE)
.tx_fixup = GobiNetDriverTxQoS,
//WORD AROUND integrated from qmi_wwan.c::qmi_wwan_rx_fixup
.rx_fixup = GobiNetDriverLteRxFixup,
#else
.rx_fixup = GobiNetDriverLteRxFixup,
#endif
.data = BIT(8) | BIT(10) | BIT(BIT_9X15),
};
#define QMI_G3K_DEVICE(vend, prod) \
USB_DEVICE(vend, prod), \
.driver_info = (unsigned long)&GobiNetInfo_gobi
#define QMI_9X15_DEVICE(vend, prod) \
USB_DEVICE(vend, prod), \
.driver_info = (unsigned long)&GobiNetInfo_9x15
/*=========================================================================*/
// Qualcomm Gobi 3000 VID/PIDs
/*=========================================================================*/
static const struct usb_device_id GobiVIDPIDTable [] =
{
// Sierra Wireless MC7750 QMI Device VID/PID
{
USB_DEVICE( 0x1199, 0x68a2 ),
.driver_info = (unsigned long)&GobiNetInfo_qmi,
},
// Gobi 3000
{QMI_G3K_DEVICE(0x05c6, 0x920d)},
{QMI_G3K_DEVICE(0x1199, 0x9011)},
{QMI_G3K_DEVICE(0x1199, 0x9013)},
{QMI_G3K_DEVICE(0x1199, 0x9015)},
{QMI_G3K_DEVICE(0x1199, 0x9019)},
{QMI_G3K_DEVICE(0x03f0, 0x371d)},
// 9x15
{QMI_9X15_DEVICE(0x1199, 0x68C0)},
{QMI_9X15_DEVICE(0x1199, 0x9041)},
{QMI_9X15_DEVICE(0x1199, 0x9051)},
{QMI_9X15_DEVICE(0x1199, 0x9053)},
{QMI_9X15_DEVICE(0x1199, 0x9054)},
{QMI_9X15_DEVICE(0x1199, 0x9055)},
{QMI_9X15_DEVICE(0x1199, 0x9056)},
{QMI_9X15_DEVICE(0x1199, 0x9061)},
//Terminating entry
{ }
};
MODULE_DEVICE_TABLE( usb, GobiVIDPIDTable );
AFAICS, this code makes the driver bind to interfaces 8 and 10 on all
QMI_9X15_DEVICEs. The BIT_9X15 is higher than any interface number in
use on these devices, and is used to trigger a slightly different QMI
startup sequence for 9x15 devices (this driver does some QMI internally,
contrary to the in-kernel driver which leaves all that to userspace).
> We are now left with interface 8 for the
> MC73xx, which is consistent with most other Sierra Wireless QMI-devices.
Well, I do have an MC7710 and it most certainly support both RMNET1 and
RMNET2 (on interface #19). So if the MC73xx is to be consistent with
other SWI QMI devices, then I would expect it to support RMNET2 as well,
only using interface #10 instead of #19. And that's how I understood
the reply from SWI in [2].
Access to these documents might require registration, but I include the
references here for completeness since these are my primary sources of
information:
[1] http://source.sierrawireless.com/resources/airprime/minicard/airprime_mc73xx_usb_driver_developers_guide/
[2] https://forum.sierrawireless.com/viewtopic.php?f=117&t=6110&p=32629#p32629
[3] http://source.sierrawireless.com/resources/airprime/software/usb-drivers-linux-qmi-software/
Bjørn
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: Derek Fawcus @ 2015-02-09 11:30 UTC (permalink / raw)
To: David Ahern
Cc: Eric W. Biederman, Stephen Hemminger, netdev, Nicolas Dichtel,
roopa, hannes, Dinesh Dutt, Vipin Kumar, Shmulik Ladkani
In-Reply-To: <54D800F5.60603@gmail.com>
On Sun, Feb 08, 2015 at 05:36:05pm -0700, David Ahern wrote:
> To make an L3 separation efficient from a large scale* perspective one
> needs to give up something
[snip]
>
> * scale here meaning VRFs from 1 to N, N for current products goes up to
> 4000, though I know of that has mentioned 16k VRFs.
FWIW - There is at least one router vendor which allows for the creation of
more than 4096 VRFs. Some of its products have a specific limitation
which may be less than the architectural maximum.
DF
^ permalink raw reply
* [PATCH] prevent the read ahead of /proc/slabinfo in ss
From: Bryton Lee @ 2015-02-09 11:37 UTC (permalink / raw)
To: stephen, netdev; +Cc: brytonlee01
ss reads ahead of /proc/slabinfo whatever slabstat will be used or not in future.
this will cause huge system delay when the kernel hires SLAB allocator(SLUB allocator is ok). when program reads
/proc/slabinfo, it will call s_show() in SLAB allocator level, and s_show() calls spin_lock_irq(&l3->list_lock)
then iterate on whole three lists. if one slab has about 900 million objects (for example dentry),
it will cause more than 1000ms delay.
so this patch prevents the read ahead of /proc/slabinfo, ss runs with most parameters not using slabstat at all.
Signed-off-by: Bryton Lee <brytonlee01@gmail.com>
---
misc/ss.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index f434f57..987dd70 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -617,6 +617,7 @@ struct slabstat
};
struct slabstat slabstat;
+int slabstat_valid = 0;
static const char *slabstat_ids[] =
{
@@ -2128,6 +2129,9 @@ static int tcp_show(struct filter *f, int socktype)
* it is able to give us some memory for snapshot.
*/
if (1) {
+ if (!slabstat_valid)
+ get_slabstat(&slabstat);
+
int guess = slabstat.socks+slabstat.tcp_syns;
if (f->states&(1<<SS_TIME_WAIT))
guess += slabstat.tcp_tws;
@@ -3157,6 +3161,9 @@ static int print_summary(void)
if (get_snmp_int("Tcp:", "CurrEstab", &sn.tcp_estab) < 0)
perror("ss: get_snmpstat");
+ if (!slabstat_valid)
+ get_slabstat(&slabstat);
+
printf("Total: %d (kernel %d)\n", s.socks, slabstat.socks);
printf("TCP: %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
@@ -3504,8 +3511,6 @@ int main(int argc, char *argv[])
argc -= optind;
argv += optind;
- get_slabstat(&slabstat);
-
if (do_summary) {
print_summary();
if (do_default && argc == 0)
--
2.0.5
^ permalink raw reply related
* [PATCH net] bridge: Fix inability to add non-vlan fdb entry
From: Toshiaki Makita @ 2015-02-09 11:16 UTC (permalink / raw)
To: David S . Miller, Stephen Hemminger; +Cc: Vlad Yasevich, netdev, bridge
Bridge's default_pvid adds a vid by default, by which we cannot add a
non-vlan fdb entry by default, because br_fdb_add() adds fdb entries for
all vlans instead of a non-vlan one when any vlan is configured.
# ip link add br0 type bridge
# ip link set eth0 master br0
# bridge fdb add 12:34:56:78:90:ab dev eth0 master temp
# bridge fdb show brport eth0 | grep 12:34:56:78:90:ab
12:34:56:78:90:ab dev eth0 vlan 1 static
We expect a non-vlan fdb entry as well as vlan 1:
12:34:56:78:90:ab dev eth0 static
To fix this, we need to insert a non-vlan fdb entry if vlan is not
specified, even when any vlan is configured.
Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
net/bridge/br_fdb.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index cc36e59..c041f99 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -840,10 +840,9 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
/* VID was specified, so use it. */
err = __br_fdb_add(ndm, p, addr, nlh_flags, vid);
} else {
- if (!pv || bitmap_empty(pv->vlan_bitmap, VLAN_N_VID)) {
- err = __br_fdb_add(ndm, p, addr, nlh_flags, 0);
+ err = __br_fdb_add(ndm, p, addr, nlh_flags, 0);
+ if (err || !pv)
goto out;
- }
/* We have vlans configured on this port and user didn't
* specify a VLAN. To be nice, add/update entry for every
@@ -911,16 +910,15 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
err = __br_fdb_delete(p, addr, vid);
} else {
- if (!pv || bitmap_empty(pv->vlan_bitmap, VLAN_N_VID)) {
- err = __br_fdb_delete(p, addr, 0);
+ err = -ENOENT;
+ err &= __br_fdb_delete(p, addr, 0);
+ if (!pv)
goto out;
- }
/* We have vlans configured on this port and user didn't
* specify a VLAN. To be nice, add/update entry for every
* vlan on this port.
*/
- err = -ENOENT;
for_each_set_bit(vid, pv->vlan_bitmap, VLAN_N_VID) {
err &= __br_fdb_delete(p, addr, vid);
}
--
1.8.1.2
^ 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