On 12/14/2018 06:12 AM, Sergey Matyukevich wrote:
> Hi Eric,
>
> This patch fixes the issue: ip forwarding works for fq/mq qdisc.
>
Thanks for testing, I will send a formal patch for IPv4 and IPv6.
On 12/14/2018 04:02 AM, Sergey Matyukevich wrote:
> Hi all,
>
> I have been running 4.18-rc8 kernel with enabled IP forwarding between
> wired and wireless interfaces, where both interfaces
> were configured as fq qdisc.
>
> However after moving to 4.20-rc1 kernel the same configuration does n
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.
What is VLA ? Sure, _now_ it
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 detected by using the Coccinelle
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 us
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 @@ void __dev_kfree_skb_irq(s
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;
> + } els
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
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 al
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 actu
i Johannes
I am afraid information is missing.
Is this a xmit or rcv problem ?
I recently fixed an issue, could this be this ?
commit 4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4
Author: Eric Dumazet
Date: Sat Oct 29 11:02:36 2016 -0700
net: mangle zero checksum in skb_checksum_help()
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 the
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
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 inet6_netconf_get_devconf
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.
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.
> PAGE_ALLOC_COST
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 certa
io
> Cc: Aloisio Almeida Jr
> Cc: Samuel Ortiz
> Signed-off-by: Cong Wang
> ---
Note that the issue is not OOM the kernel (as the allocation is
attempted even after your patch), but having a way to
spill stack traces in the syslog.
Acked-by: Eric Dumazet
Thanks!
--
To u
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.
>
memcpy_from_m
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 this is called
> > from userspace would be nice (I'm
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 kmem
Signed-off-by: Emmanuel Grumbach
> ---
> v3: use vlan_get_protocol and call it once in tso_start
> store the result in tso_t
Acked-by: Eric Dumazet
Next step, adding encapsulation support ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" i
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.
> + be16_add
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 lea
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
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 --git a/net/nfc/llcp_soc
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 gso_max
On Thu, 2015-08-20 at 13:53 +, Grumbach, Emmanuel wrote:
> I do keep the original skb: it becomes the first 802.11 packet generated
> from that LSO skb. Thing is that it will be freed first and I wanted the
> *last packet* to release the pressure on the socket.
Just change this to free it las
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 / T
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
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 s
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
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
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. LSO gives me the guarantee that the packet is
> directed to one peer, which might not be the case with xmit_more si
On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote:
> This allows to release the backpressure on the socket only
> when the last segment is released.
> Now the truesize looks like this:
> if the truesize of the original skb is 65420, all the
> segments will have a truesize of 704 (skb itsel
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.
&g
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 / T
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.
On Tue, 2015-03-03 at 12:24 +0800, Fred Chou wrote:
> From: Fred Chou
>
> 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
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 12 ++--
On Mon, 2015-03-02 at 17:17 -0500, David Miller wrote:
> From: Eric Dumazet
> 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
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
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
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
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))
> > /
> > +
On Tue, 2015-02-10 at 08:54 +, Colin King wrote:
> From: Colin Ian King
>
> 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: Colin Ian King
> ---
On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote:
>ath10k_core_napi_dummy_poll, 64);
> + ewma_init(&ar->tx_delay_us, 16384, 8);
1) 16384 factor might be too big.
2) a weight of 8 seems too low given aggregation values used in wifi.
On 32bit arches, the ma
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
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);
> +
> + ACCESS_ONCE(msdu->sk->sk_t
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_no
On Fri, 2015-02-06 at 14:31 +, David Laight wrote:
> From: Eric Dumazet
> > 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 driv
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
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, ether
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 a
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 p
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 sti
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
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 @@
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
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 o
On Thu, 2015-02-05 at 07:46 +0100, Michal Kazior wrote:
> On 4 February 2015 at 22:11, Eric Dumazet wrote:
> > Most conservative patch would be :
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
> > b/drivers/net/wireless/at
On Thu, 2015-02-05 at 09:38 +0100, Michal Kazior wrote:
> On 4 February 2015 at 22:11, Eric Dumazet 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 bo
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.
On Wed, 2015-02-04 at 05:16 -0800, Eric Dumazet wrote:
> 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-sc
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 t
On Wed, 2015-02-04 at 13:22 +0100, Michal Kazior wrote:
> On 4 February 2015 at 12:57, Eric Dumazet 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:
>
> ; ethto
On Wed, 2015-02-04 at 12:35 +0100, Michal Kazior wrote:
> > (Or maybe wifi drivers should start to use skb->xmit_more as a signal to
> > end aggregation)
>
> This could work if your firmware/device supports this kind of thing.
> To my understanding ath10k firmware doesn't.
This is a pure softwa
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 h
On Tue, 2015-02-03 at 12:50 +0100, Michal Kazior wrote:
> On 3 February 2015 at 02:18, Eric Dumazet wrote:
> > 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_sh
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 sp
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 stret
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 some
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 th
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 sug
On Fri, 2015-01-30 at 11:29 +0100, Arend van Spriel wrote:
> Hi Eric,
>
> Your suggestions are still based on the fact that you consider wireless
> networking to be similar to ethernet, but as Michal indicated there are
> some fundamental differences starting with CSMA/CD versus CSMA/CA. Also
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
> (d
75 matches
Mail list logo