Skip to content

L
linux
Switch branch/tag
  1. 07 May, 2020 8 commits
    • David S. Miller's avatar
      Merge branch 'tcp-minor-adjustments-for-low-pacing-rates' · ee733cd8
      David S. Miller authored 
      Eric Dumazet says:

====================
tcp: minor adjustments for low pacing rates

After pacing horizon addition, we have to adjust how we arm rto
timer, otherwise we might freeze very low pacing rate flows.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee733cd8
    • Eric Dumazet's avatar
      tcp: defer xmit timer reset in tcp_xmit_retransmit_queue() · 916e6d1a
      Eric Dumazet authored 
      As hinted in prior change ("tcp: refine tcp_pacing_delay()
for very low pacing rates"), it is probably best arming
the xmit timer only when all the packets have been scheduled,
rather than when the head of rtx queue has been re-sent.

This does matter for flows having extremely low pacing rates,
since their tp->tcp_wstamp_ns could be far in the future.

Note that the regular xmit path has a stronger limit
in tcp_small_queue_check(), meaning it is less likely to
go beyond the pacing horizon.
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      916e6d1a
    • Eric Dumazet's avatar
      tcp: refine tcp_pacing_delay() for very low pacing rates · 8dc242ad
      Eric Dumazet authored 
      With the addition of horizon feature to sch_fq, we noticed some
suboptimal behavior of extremely low pacing rate TCP flows, especially
when TCP is not aware of a drop happening in lower stacks.

Back in commit 3f80e08f ("tcp: add tcp_reset_xmit_timer() helper"),
tcp_pacing_delay() was added to estimate an extra delay to add to standard
rto timers.

This patch removes the skb argument from this helper and
tcp_reset_xmit_timer() because it makes more sense to simply
consider the time at which next packet is allowed to be sent,
instead of the time of whatever packet has been sent.

This avoids arming RTO timer too soon and removes
spurious horizon drops.
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dc242ad
    • Alex Elder's avatar
      arm64: dts: sdm845: add IPA iommus property · b94c280d
      Alex Elder authored 
      Add an "iommus" property to the IPA node in "sdm845.dtsi".  It is
required because there are two regions of memory the IPA accesses
through an SMMU.  The next few patches define and map those regions.
Signed-off-by: default avatarAlex Elder <elder@linaro.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b94c280d
    • David S. Miller's avatar
      Merge branch 'timer-add-fsleep-for-flexible-sleeping' · a88845d8
      David S. Miller authored 
      Heiner Kallweit says:

====================
timer: add fsleep for flexible sleeping

Sleeping for a certain amount of time requires use of different
functions, depending on the time period.
Documentation/timers/timers-howto.rst explains when to use which
function, and also checkpatch checks for some potentially
problematic cases.

So let's create a helper that automatically chooses the appropriate
sleep function -> fsleep(), for flexible sleeping
Not sure why such a helper doesn't exist yet, or where the pitfall is,
because it's a quite obvious idea.

If the delay is a constant, then the compiler should be able to ensure
that the new helper doesn't create overhead. If the delay is not
constant, then the new helper can save some code.

First user is the r8169 network driver. If nothing speaks against it,
then this series could go through the netdev tree.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a88845d8
    • Heiner Kallweit's avatar
      r8169: use fsleep in polling functions · d6836ef0
      Heiner Kallweit authored 
      Use new flexible sleep function fsleep() to merge the udelay and msleep
polling functions. We can safely do this because no polling function
is used in atomic context in this driver.
Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6836ef0
    • Heiner Kallweit's avatar
      timer: add fsleep for flexible sleeping · c6af13d3
      Heiner Kallweit authored 
      Sleeping for a certain amount of time requires use of different
functions, depending on the time period.
Documentation/timers/timers-howto.rst explains when to use which
function, and also checkpatch checks for some potentially
problematic cases.

So let's create a helper that automatically chooses the appropriate
sleep function -> fsleep(), for flexible sleeping

If the delay is a constant, then the compiler should be able to ensure
that the new helper doesn't create overhead. If the delay is not
constant, then the new helper can save some code.
Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6af13d3
    • Fernando Gont's avatar
      ipv6: Implement draft-ietf-6man-rfc4941bis · 969c5464
      Fernando Gont authored 
      Implement the upcoming rev of RFC4941 (IPv6 temporary addresses):
https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-09

* Reduces the default Valid Lifetime to 2 days
  The number of extra addresses employed when Valid Lifetime was
  7 days exacerbated the stress caused on network
  elements/devices. Additionally, the motivation for temporary
  addresses is indeed privacy and reduced exposure. With a
  default Valid Lifetime of 7 days, an address that becomes
  revealed by active communication is reachable and exposed for
  one whole week. The only use case for a Valid Lifetime of 7
  days could be some application that is expecting to have long
  lived connections. But if you want to have a long lived
  connections, you shouldn't be using a temporary address in the
  first place. Additionally, in the era of mobile devices, general
  applications should nevertheless be prepared and robust to
  address changes (e.g. nodes swap wifi <-> 4G, etc.)

* Employs different IIDs for different prefixes
  To avoid network activity correlation among addresses configured
  for different prefixes

* Uses a simpler algorithm for IID generation
  No need to store "history" anywhere
Signed-off-by: default avatarFernando Gont <fgont@si6networks.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      969c5464
  3. 06 May, 2020 29 commits
  5. 05 May, 2020 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7