To revive an old thread ...
On Mon, 2015-02-09 at 07:11 -0800, Eric Dumazet wrote:
> 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, lim
On Tue, 2015-02-24 at 11:30 +0100, Johannes Berg wrote:
> On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote:
> > On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
> >
> > > > Good point. I was actually thinking about it. I can try cooking a
> > > > patch unless you want to do it yoursel
On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote:
> On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
>
> > > Good point. I was actually thinking about it. I can try cooking a
> > > patch unless you want to do it yourself :-)
> >
> > I've taken a look into this. The most obvious place
On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote:
> > Good point. I was actually thinking about it. I can try cooking a
> > patch unless you want to do it yourself :-)
>
> I've taken a look into this. The most obvious place to add the
> timestamp for each packet would be ieee80211_tx_info (
On Wed, Feb 11, 2015 at 11:48 PM, Michal Kazior wrote:
> On 11 February 2015 at 09:57, Michal Kazior wrote:
>> On 10 February 2015 at 15:19, Johannes Berg
>> wrote:
>>> On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote:
>>>
+ if (msdu->sk) {
+ ewma_add(&ar->tx
On 11 February 2015 at 09:57, Michal Kazior wrote:
> On 10 February 2015 at 15:19, 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
On 11 February 2015 at 14:17, Eric Dumazet wrote:
> 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
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 10 February 2015 at 15:19, 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)) /
>> +NSEC_
On 10 February 2015 at 14:14, Eric Dumazet wrote:
> 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 g
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 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 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 divide, as the compiler will use
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 9 February 2015 at 16:11, Eric Dumazet wrote:
> On Mon, 2015-02-09 at 14:47 +0100, Michal Kazior wrote:
[...]
> 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
> l
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 6 February 2015 at 15:09, Michal Kazior wrote:
> On 6 February 2015 at 14:53, Eric Dumazet 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 exp
If you increase ability to flood on one flow, then you need to make sure
receiver has big rcvbuf as well.
echo 200 >/proc/sys/net/core/rmem_default
Otherwise it might drop bursts.
This is the kind of things that TCP does automatically, not UDP.
An alternative, if the application involved
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 driver.
> >
> > This way, we would have no penalty for network devices doing normal skb
> > orphaning (loopback in
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 driver.
> > >
> > > This way, we would have no
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, ethernet, ...)
Another w
On 6 February 2015 at 14:53, Eric Dumazet 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 tc
On 6 February 2015 at 14:40, Eric Dumazet wrote:
> 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 n
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 = m
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 5 February 2015 at 20:50, Dave Taht wrote:
[...]
> And I really, really, really wish, that just once during this thread,
> someone had bothered to try running a test
> at a real world MCS rate - say MCS1, or MCS4, and measured the latency
> under load of that...
Time between frame submission t
On 5 February 2015 at 18:10, Eric Dumazet wrote:
> 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
On 05/02/2015 15:48, Eric Dumazet wrote:
> 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
On Fri, Feb 6, 2015 at 2:44 AM, Michal Kazior wrote:
>
> On 5 February 2015 at 14:19, Eric Dumazet wrote:
> > 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 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 increasi
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 5 February 2015 at 14:19, Eric Dumazet wrote:
> 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.
>>
>>
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 and
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 dest
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/ath/ath10k/htt_rx.c
> > index
> > 9c782a42665e1aaf43bfbca441
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 bool tcp_write_xmit(struct sock *sk,
> unsigned
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 bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
* of queued bytes to ensure li
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.
>
> ath10k tx completions being batched/deferred to a tasklet might increase
> probability to hit this condition in tcp_wfree() :
>
> /* If this sof
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-scatter-gather: off
> generic-
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:53 +0100, Michal Kazior wrote:
> The hardware itself seems to be capable. The firmware is a problem
> though. I'm also not sure if mac80211 can handle this as is. No 802.11
> driver seems to support SG except wil6210 which uses cfg80211 and
> netdevs directly.
mac80211 ca
On 4 February 2015 at 13:38, Eric Dumazet wrote:
> 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 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:
>
> ; ethtool -K wlan1 gso on
> Could not change any
On 4 February 2015 at 12:57, Eric Dumazet wrote:
> 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 unde
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 3 February 2015 at 15:27, Eric Dumazet wrote:
> On Tue, 2015-02-03 at 12:50 +0100, Michal Kazior wrote:
[...]
>> IOW:
>> - stretch acks / TSO defer don't seem to help much (when compared to
>> throughput results from yesterday)
>> - GRO helps
>> - disabling A-MSDU on sender helps
>> - net/m
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")
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_should_defer(), which relies on ACK bei
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_should_defer(), which relies on ACK being received smoothly, as
>> no timer is setup to split the TSO pac
On 3 February 2015 at 00:06, Eric Dumazet wrote:
> 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 stil
On 2 February 2015 at 19:52, Eric Dumazet wrote:
> 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.
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 lo
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 02/02/2015 10:52 AM, Eric Dumazet wrote:
> 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.
>
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 30 January 2015 at 15:40, Eric Dumazet wrote:
> 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 dr
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 01/30/15 14:19, Eric Dumazet wrote:
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
On 29 January 2015 at 14:14, Eric Dumazet wrote:
> 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"`.
>>
>>
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 01/29/15 14:14, Eric Dumazet wrote:
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 perfo
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
67 matches
Mail list logo
