- Feb 07, 2019
-
-
Aastha Mehta authored
-
- Feb 03, 2019
-
-
Aastha Mehta authored
we are scheduling napi after nic interrupts have been re-enabled. so in principle we can be interrupted.
-
- Jan 31, 2019
-
-
Aastha Mehta authored
-
- Jan 30, 2019
-
-
-
Aastha Mehta authored
-
- Jan 19, 2019
-
-
Aastha Mehta authored
-
- Jan 16, 2019
-
-
Aastha Mehta authored
-
- Jan 14, 2019
-
-
Aastha Mehta authored
-
- Jan 09, 2019
-
-
Aastha Mehta authored
-
- Jan 08, 2019
-
-
Aastha Mehta authored
-
- Dec 28, 2018
-
-
Aastha Mehta authored
-
- Dec 27, 2018
-
-
Aastha Mehta authored
we dont want to send non-MTU packets, so no point in fragmenting a buffer
-
Aastha Mehta authored
-
- Dec 24, 2018
-
-
Aastha Mehta authored
-
- Dec 20, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Nov 29, 2018
-
-
Aastha Mehta authored
-
- Nov 28, 2018
-
-
Aastha Mehta authored
bugfix: in undo_cwnd_reduction iterate through skb queue and mark all lost pkts as unlost irrespective of snd_head
-
Aastha Mehta authored
-
- Nov 27, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Nov 25, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Nov 20, 2018
-
-
Aastha Mehta authored
-
- Nov 16, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Nov 15, 2018
-
-
Aastha Mehta authored
bugfixes: storing cwnd prior to loss or recovery state for subsequent restoration under undo_cwnd_reduction (1) in ptcp_enter_loss, store prior cwnd value only if entering loss the first time. if entering loss (CA 4) from recovery or CWR state, copy the prior_cwnd into loss_prior_cwnd. (2) during undo_cwnd_reduction, restore to loss_prior_cwnd if state is Loss, otherwise restore to prior_cwnd.
-
Aastha Mehta authored
avoid coalescing by setting net.ipv4.tcp_retrans_collapse = 0
-
- Nov 14, 2018
-
-
Aastha Mehta authored
(1) first retract cwnd and hypace cwm (2) then sync packet counts (3) then mark packets upto packet_count as lost this has a small problem where a packet unsent in tcp with lower seq# is marked lost, whereas a dummy with a higher seq# that was actually sent must be treated as not lost. potentially it looks as if there were losses in the middle of a stream but subsequent packets were transmitted even before recovering from the intermediate losses.
-
- Nov 13, 2018
-
-
Aastha Mehta authored
-
- Nov 12, 2018
-
-
Aastha Mehta authored
fixes issue#22
-
- Nov 11, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Nov 06, 2018
-
-
Aastha Mehta authored
-
- Oct 04, 2018
-
-
Roberta De Viti authored
-
- Oct 03, 2018
-
-
Aastha Mehta authored
-
Aastha Mehta authored
-
- Oct 01, 2018
-
-
Roberta De Viti authored
-