Re: [PATCH] drivers: net: wireless: ath: ath9k: dfs: remove VLA usage

On 03/09/2018 05:23 AM, Andreas Christoforou wrote: The kernel would like to have all stack VLA usage removed. This is the correct patch. Signed-off-by: Andreas Christoforou This is a lazy changelog really. 'This is the correct patch' has no technical value.

Re: [PATCH] wil6210: Replace five seq_puts() calls by seq_putc()

On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 8 May 2017 22:22:04 +0200 > > Five single characters (line breaks) should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was

Re: [PATCH v2] brcmfmac: Make skb header writable before use

On Mon, 2017-04-24 at 14:03 +0100, James Hughes wrote: > The driver was making changes to the skb_header without > ensuring it was writable (i.e. uncloned). > This patch also removes some boiler plate header size > checking/adjustment code as that is also handled by the > skb_cow_header function

Re: [PATCH] p54: add null pointer check before releasing socket buffer

On Mon, Apr 10, 2017 at 2:22 PM, Christian Lamparter wrote: > Well, the patch could be as simple as this: > --- > diff --git a/net/core/dev.c b/net/core/dev.c > index 7869ae3837ca..44f7d5a1c67c 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2450,6 +2450,9 @@

Re: [Make-wifi-fast] [PATCH v3] mac80211: Dynamically set CoDel parameters per station

On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote: > + > + if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { > + sta->cparams.target = MS2TIME(50); > + sta->cparams.interval = MS2TIME(300); > + sta->cparams.ecn = false; > + }

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote: > > > Unfortunately, I haven't been able to actually test this yet. I also > > didn't find the code that would drop frames with CSUM 0 either, so I'm >

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote: > Unfortunately, I haven't been able to actually test this yet. I also > didn't find the code that would drop frames with CSUM 0 either, so I'm > thinking - for now - that if all the csum handling is skipped, dropping > 0 csum frames would

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote: > Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY", > nothing more advanced right now, but right now we'd indicate that if > the packet had 0x in the checksum field, but should've had 0x. > > On TX I believe we

Re: IPv6-UDP 0x0000 checksum

is missing. Is this a xmit or rcv problem ? I recently fixed an issue, could this be this ? commit 4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4 Author: Eric Dumazet <eduma...@google.com> Date: Sat Oct 29 11:02:36 2016 -0700 net: mangle zero checksum in skb_checksum_help()

Re: [Make-wifi-fast] On the ath9k performance regression with FQ and crypto

Do you have tcpdumps of 1) sample with crypto 2) sample without crypto. Looks like some TCP Small queue interaction with skb->truesize, if GSO is involved, or encapsulation adding overhead. On Tue, 2016-08-16 at 22:41 +0200, Toke Høiland-Jørgensen wrote: > So Dave and I have been spending

Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()

On Fri, 2016-07-08 at 12:15 +0900, Masashi Honma wrote: = > Thanks for comment. > > I have selected GFP flags based on existing code. > > I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because > skb was allocated with GFP_ATOMIC. Point is : we should remove GFP_ATOMIC uses as much as

Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()

On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote: > Signed-off-by: Masashi Honma > --- > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index a1f6b7b..2b0b994 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -628,7 +628,7 @@ static int

Re: [Codel] [PATCHv3 2/5] mac80211: implement fair queueing per txq

On Mon, 2016-04-18 at 07:16 +0200, Michal Kazior wrote: > > I guess .h file can give the compiler an opportunity for more > optimizations. With .c you would need LTO which I'm not sure if it's > available everywhere. > This makes little sense really. Otherwise everything would be in .h files.

Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

On Tue, 2016-03-29 at 17:27 +0800, Wei-Ning Huang wrote: > Adding some chromium devs to the thread. > > In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152 > > The default mm retry allocation when 'order <= > PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT. >

Re: [PATCH] codel: add forgotten inline to functions in header file

On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote: > Yeah :) codel_should_drop seemed very long indeed... I wanted to use the > codel_get_time and associated utils (_before, _after) in iwlwifi. > They're better than jiffies... So maybe I can just copy that code to > iwlwifi. You

Re: [PATCH v2 net] nfc: use GFP_USER for user-controlled kmalloc

cation is attempted even after your patch), but having a way to spill stack traces in the syslog. Acked-by: Eric Dumazet <eduma...@google.com> Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

On Wed, 2016-01-27 at 11:50 -0800, Cong Wang wrote: > Hmm? I think nfc_llcp_send_ui_frame() needs to do some fragmention > with this temporary memory, or you are saying msg_iter has some > API available to seek the pointer? Even if so, it doesn't look like > suitable for -stable. >

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

On Tue, 2016-01-26 at 15:12 -0800, Cong Wang wrote: > On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby > wrote: > > Hi Cong, > > > > On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote: > > > > A commit message would be nice. A brief rundown of how

Re: [v2] ath6kl: Use vmalloc to allocate ar->fw for api1 method

On Tue, 2015-12-01 at 22:18 -0600, Brent Taylor wrote: > Since commit 8437754c8335 ("ath6kl: Use vmalloc instead of kmalloc for > fw") ar->fw is expected to be pointing to memory allocated by vmalloc. > If the api1 method (via ath6kl_fetch_fw_api1) is used to allocate memory > for ar->fw, then

Re: [PATCH v3] net: tso: add support for IPv6

Emmanuel Grumbach <emmanuel.grumb...@intel.com> > --- > v3: use vlan_get_protocol and call it once in tso_start > store the result in tso_t Acked-by: Eric Dumazet <eduma...@google.com> Next step, adding encapsulation support ;) -- To unsubscribe from this list: se

Re: [RFC v3 2/2] iwlwifi: mvm: send large SKBs to the transport

On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote: > + > + if (skb->protocol == htons(ETH_P_IP)) { > + ip_hdr(tmp)->id = ip_hdr(skb)->id; Too late, you already called consume_skb(skb). So this is a potential use after free. > +

Re: [RFC v3 1/2] iwlwifi: pcie: allow to build an A-MSDU using TSO core

On Thu, 2015-10-22 at 00:14 +, Grumbach, Emmanuel wrote: > > Well. I guess I should at least check, but even with very small MSS, our > device supports up to 20 pointers for the same 802.11 packet: 2 are for > metadata. So basically, so leaves me only 18 pointers. for each MSS I > need at

Re: [RFC v3 1/2] iwlwifi: pcie: allow to build an A-MSDU using TSO core

On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote: > When the op_mode sends an skb whose payload is bigger than > MSS, PCIe will create an A-MSDU out of it. PCIe assumes > that the skb that is coming from the op_mode can fit in one > A-MSDU. It is the op_mode's responsibility to make sure

Re: [PATCH] nfc: free skb buffer using skb_free_datagram

On Mon, 2015-10-19 at 15:59 +, Insu Yun wrote: > Freeing sk_buff genereated by skb_recv_datagram is always by > skb_free_datagram, not kfree_skb. > > Signed-off-by: Insu Yun > --- > net/nfc/llcp_sock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote: On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers keep around the original LSO packet

Re: [RFC v3 1/3] iwlwifi: mvm: add real TSO implementation

On Thu, 2015-08-20 at 11:15 +0300, Emmanuel Grumbach wrote: The segmentation is done completely in software. The driver creates several MPDUs out of a single large send. Each MPDU is a newly allocated SKB. A page is allocated to create the headers that need to be duplicated (SNAP / IP / TCP).

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On Thu, 2015-08-20 at 19:34 +, Grumbach, Emmanuel wrote: Err... no :( It won't work for me because the MSS impacts the number of segments which in turns impact the number of time the headers have to be copied which impacts... the A-MSDU maximal size which must be bigger than

Re: [RFC v2 1/3] iwlwifi: mvm: add real TSO implementation

On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: The segmentation is done completely in software. The driver creates several MPDUs out of a single large send. Each MPDU is a newly allocated SKB. A page is allocated to create the headers that need to be duplicated (SNAP / IP / TCP).

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: We could have enabled A-MSDU based on xmit-more, but the rationale of using LSO is that when using pfifo-fast, the Qdisc gets one packet and dequeues is straight away which limits the possibility to get a lot of packets at once. (Am

Re: [RFC v2 1/3] iwlwifi: mvm: add real TSO implementation

On Wed, 2015-08-19 at 07:17 -0700, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: The segmentation is done completely in software. The driver creates several MPDUs out of a single large send. Each MPDU is a newly allocated SKB. A page is allocated

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On Wed, 2015-08-19 at 17:00 +, Grumbach, Emmanuel wrote: On 08/19/2015 07:08 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:07 +, Grumbach, Emmanuel wrote: I'll look at it. I was almost starting to implement that but then I thought with another (good?) reason to use LSO

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On Wed, 2015-08-19 at 17:56 +, Grumbach, Emmanuel wrote: So I feel that making net/core/tso.c more complicated just because of our craziness seems an overkill to me. I'll try a bit harder to see how I can use net/core/tso.c, but I have to say I am pessimistic. net/core/tso.c is WIP,

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers keep around the original LSO packet and frees it normally at TX completion time. I can't see anything related to truesize there. Note that this work

Re: [PATCH RFC 00/14] shrink skb cb to 44 bytes

On Mon, 2015-03-02 at 21:42 +0100, Florian Westphal wrote: Thats right. Do you think its worth to already move cb[] near the end of skb and alter build_skb to not clear it anymore? Which of the ideas, in your opinion, is worth pursuing first (if any)? moving cb[] near the end will void my

Re: [PATCH RFC 00/14] shrink skb cb to 44 bytes

On Mon, 2015-03-02 at 17:17 -0500, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Mon, 02 Mar 2015 11:49:23 -0800 Size of skb-cb[] is not the major factor. Trying to gain 4 or 8 bytes is not going to improve performance a lot. The real problem is that we clear

Re: [PATCH] ath9k_htc: avoid memcpy when downloading firmware

On Tue, 2015-03-03 at 12:24 +0800, Fred Chou wrote: From: Fred Chou fred.chou...@gmail.com The temporary buffer to hold firmware data is not really needed, and memcpy can be avoided by using data pointer instead. Signed-off-by: Fred Chou fred.chou...@gmail.com ---

Re: [PATCH RFC 00/14] shrink skb cb to 44 bytes

On Mon, 2015-03-02 at 18:40 +0100, Florian Westphal wrote: Following patches shrink all in-tree users of skb-cb[] so that kernel still builds with skb-cb[] set to 44 bytes. This would create a 4-byte hole, it would be easy to reorder skb members so this hole is filled. pahole dump for

Re: Throughput regression with `tcp: refine TSO autosizing`

On Wed, 2015-02-11 at 09:33 +0100, Michal Kazior wrote: If I set tcp_limit_output_bytes to 700K+ I can get ath10k w/ cushion w/ aggregation to reach 600mbps on a single flow. You know, there is a reason this sysctl exists in the first place ;) The first suggestion I made to you was to raise

Re: Throughput regression with `tcp: refine TSO autosizing`

On Tue, 2015-02-10 at 15:19 +0100, Johannes Berg wrote: On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote: + if (msdu-sk) { + ewma_add(ar-tx_delay_us, +ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)) / +

Re: Throughput regression with `tcp: refine TSO autosizing`

On Tue, 2015-02-10 at 04:54 -0800, Eric Dumazet wrote: Hi Michal This is almost it ;) As I said you must do this using u64 arithmetics, we still support 32bit kernels. Also, 20 instead of / 100 introduces a 5% error, I would use a plain divide, as the compiler will use

Re: [PATCH] rtlwifi: ratelimit skb allocation failure message

On Tue, 2015-02-10 at 08:54 +, Colin King wrote: From: Colin Ian King colin.k...@canonical.com when running low on memory I noticed rtlwifi was producing a large quantity of repeated skb allocation failures messages. This should be ratelimited to reduce the noise. Signed-off-by:

Re: Throughput regression with `tcp: refine TSO autosizing`

On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote: + if (msdu-sk) { + ewma_add(ar-tx_delay_us, +ktime_to_ns(ktime_sub(ktime_get(), skb_cb-stamp)) / +NSEC_PER_USEC); + +

Re: Throughput regression with `tcp: refine TSO autosizing`

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,

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, 2015-02-06 at 05:53 -0800, Eric Dumazet wrote: 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, ...) Another way

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, 2015-02-06 at 15:08 +0100, Michal Kazior wrote: Hmm.. I confirm it works. However the value at which I get full rate on a single flow is more than 2048K. Also using non-default wmem_default seems to introduce packet loss as per iperf reports at the receiver. I suppose this is kind of

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, 2015-02-06 at 10:42 +0100, Michal Kazior wrote: The above brings back previous behaviour, i.e. I can get 600mbps TCP on 5 flows again. Single flow is still (as it was before TSO autosizing) limited to roughly ~280mbps. I never really bothered before to understand why I need to push

Re: Throughput regression with `tcp: refine TSO autosizing`

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

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 07:46 +0100, Michal Kazior wrote: On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote: Most conservative patch would be : diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c index

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote: The intention is to control the queues to the following : 1 ms of buffering, but limited to a configurable value. On a 40Gbps flow, 1ms represents 5 MB, which is insane. We do not want to queue 5 MB of traffic, this would destroy

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 05:19 -0800, Eric Dumazet wrote: TCP could eventually dynamically adjust the tcp_limit_output_bytes, using a per flow dynamic value, but I would rather not add a kludge in TCP stack only to deal with a possible bug in ath10k driver. niu has a similar issue

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 09:38 +0100, Michal Kazior wrote: On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote: I do not see how a TSO patch could hurt a flow not using TSO/GSO. This makes no sense. Hmm.. @@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock *sk

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote: I do get your point. But 1.5ms is really tough on Wi-Fi. Just look at this: ; ping 192.168.1.2 -c 3 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.83 ms 64 bytes from

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote: Ok. I tried calling skb_orphan() right after I submit each Tx frame (similar to niu which does this in start_xmit): --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -564,6 +564,8 @@ int

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-02-05 at 06:41 -0800, Eric Dumazet wrote: Not at all. This basically removes backpressure. A single UDP socket can now blast packets regardless of SO_SNDBUF limits. This basically remove years of work trying to fix bufferbloat. I still do not understand why increasing

Re: Throughput regression with `tcp: refine TSO autosizing`

I do not see how a TSO patch could hurt a flow not using TSO/GSO. This makes no sense. ath10k tx completions being batched/deferred to a tasklet might increase probability to hit this condition in tcp_wfree() : /* If this softirq is serviced by ksoftirqd, we are likely under stress.

Re: Throughput regression with `tcp: refine TSO autosizing`

On Wed, 2015-02-04 at 13:22 +0100, Michal Kazior wrote: On 4 February 2015 at 12:57, Eric Dumazet eric.duma...@gmail.com wrote: To disable gso you would have to use : ethtool -K wlan1 gso off Oh, thanks! This works. However I can't turn it on: ; ethtool -K wlan1 gso on Could

Re: Throughput regression with `tcp: refine TSO autosizing`

OK guys Using a mlx4 testbed I can reproduce the problem by pushing coalescing settings and disabling SG (thus disabling GSO) ethtool -K eth0 sg off Actual changes: scatter-gather: off tx-scatter-gather: off generic-segmentation-offload: off [requested on] ethtool -C eth0 tx-usecs 1024

Re: Throughput regression with `tcp: refine TSO autosizing`

On Tue, 2015-02-03 at 06:27 -0800, Eric Dumazet wrote: Are packets TX completed after a timer or something ? Some very heavy stuff might run from tasklet (or other softirq triggered) event. Right, commit 6c5151a9ffa9f796f2d707617cecb6b6b241dff8 (ath10k: batch htt tx/rx completions

Re: Throughput regression with `tcp: refine TSO autosizing`

On Mon, 2015-02-02 at 10:52 -0800, Eric Dumazet wrote: It seems to break ACK clocking badly (linux stack has a somewhat buggy tcp_tso_should_defer(), which relies on ACK being received smoothly, as no timer is setup to split the TSO packet.) Following patch might help the TSO split defer

Re: Throughput regression with `tcp: refine TSO autosizing`

On Mon, 2015-02-02 at 13:25 -0800, Ben Greear wrote: It is a big throughput win to have fewer TCP ack packets on wireless since it is a half-duplex environment. Is there anything we could improve so that we can have fewer acks and still get good tcp stack behaviour? First apply TCP stretch

Re: Throughput regression with `tcp: refine TSO autosizing`

On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote: While testing I've had my internal GRO patch for ath10k and no stretch ack patches. Thanks for the data, I took a look at it. I am afraid this GRO patch might be the problem. It seems to break ACK clocking badly (linux stack has a

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, 2015-01-30 at 14:47 +0100, Arend van Spriel wrote: Indeed and that is what we would like to address in our wireless drivers. I will setup some experiments using the fraction sizing and post my findings. Again sorry if I offended you. You did not, but I had no feedback about my

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, 2015-01-30 at 14:39 +0100, Michal Kazior wrote: I've briefly tried playing with this knob to no avail unfortunately. I tried 256K, 1M - it didn't improve TCP performance. When I tried to make it smaller (e.g. 16K) the traffic dropped even more so it does have an effect. It seems

Re: Throughput regression with `tcp: refine TSO autosizing`

On Thu, 2015-01-29 at 12:48 +0100, Michal Kazior wrote: Hi, I'm not subscribed to netdev list and I can't find the message-id so I can't reply directly to the original thread `BW regression after tcp: refine TSO autosizing`. I've noticed a big TCP performance drop with ath10k