From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Bill Ver Steeg (versteb)" <versteb@cisco.com>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] sch_fq and sk->sk_pacing_rate
Date: Mon, 27 Apr 2015 08:30:48 -0700 [thread overview]
Message-ID: <1430148648.22254.223.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <AE7F97DB5FEE054088D82E836BD15BE9319C342B@xmb-aln-x05.cisco.com>
Hi Bill
I am confused, because it looks like this is already there in the kernel
Look for SO_MAX_PACING_RATE setsockopt() ?
It works for all sockets, not only TCP ;)
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=62748f32d501f5d3712a7c372bbb92abc7c62bc7
Instead of doing the test in sch_fq (under potential qdisc lock),
its done in TCP (under socket spinlock, which is more scalable)
On Mon, 2015-04-27 at 14:49 +0000, Bill Ver Steeg (versteb) wrote:
> Bloaters (and particularly Eric)
>
>
>
> I will try to not confuse the list, as this question is about host
> behaviors rather than middlebox behaviors. Having said that……
>
>
>
> I am playing around with some application code that would benefit from
> pacing. The example I have in mind is MPEG-DASH style vide, but any
> type of ABR flow would probably benefit from the scheme I have in
> mind. I have done some work with client based pacing via RWND, but it
> is very clunky.
>
>
>
> I am thinking of having the server tell the kernel the rate at which
> it wants data delivered to the client. (The client would probably tell
> the server via an HTTP pragma, but that is a separate can of worms….)
> So, the HTTP server would tell the kernel that it wants to deliver the
> TCP data at or below a certain max rate. There are currently hooks in
> sch_fq for the TCP layer to set sk_pacing_rate. It seems that I would
> need to add another pacing variable and have the data sent at the min
> of q->flow_max_rate, skb->sk->sk_pacing_rate, and this new
> app_pacing_rate. In other words, the old code
>
>
>
> rate = q->flow_max_rate;
> if (skb->sk)
> rate = min(skb->sk->sk_pacing_rate, rate);
>
>
>
> would become
>
>
>
> rate = q->flow_max_rate;
> if (skb->sk)
> {
> rate = min(skb->sk->sk_pacing_rate, rate);
> if (skb->sk->app_pacing_rate)
> rate = (min(skb->sk->app_pacing_rate, rate);
> }
>
>
>
>
>
> Thoughts?
>
>
>
> Bill VerSteeg
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2015-04-27 15:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 14:49 Bill Ver Steeg (versteb)
2015-04-27 15:30 ` Eric Dumazet [this message]
2015-04-27 14:56 Bill Ver Steeg (versteb)
2015-04-27 15:15 ` Steinar H. Gunderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430148648.22254.223.camel@edumazet-glaptop2.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=versteb@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox