On 7/9/20 11:21 PM, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 11:07 PM YU, Xiangning
> wrote:
>>
>>
>> On 7/9/20 10:20 PM, Cong Wang wrote:
>>> On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
IOW, without these *additional* efforts, it is broken in terms of
out-of-order.
>>>
>>
On 7/9/20 11:09 PM, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 10:49 PM YU, Xiangning
> wrote:
>>
>> Well, we do ask packets from a flow to be classified to a single class, not
>> multiple ones. It doesn't have to be socket priority, it could be five tuple
>> hash, or even container classid.
>
On Thu, Jul 9, 2020 at 11:07 PM YU, Xiangning
wrote:
>
>
> On 7/9/20 10:20 PM, Cong Wang wrote:
> > On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> >> IOW, without these *additional* efforts, it is broken in terms of
> >> out-of-order.
> >>
> >
> > Take a look at fq_codel, it provides a hash f
On Thu, Jul 9, 2020 at 10:49 PM YU, Xiangning
wrote:
>
> Well, we do ask packets from a flow to be classified to a single class, not
> multiple ones. It doesn't have to be socket priority, it could be five tuple
> hash, or even container classid.
I don't see how it is so in your code, without s
On 7/9/20 10:20 PM, Cong Wang wrote:
> On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
>> IOW, without these *additional* efforts, it is broken in terms of
>> out-of-order.
>>
>
> Take a look at fq_codel, it provides a hash function for flow classification,
> fq_codel_hash(), as default, thus
On 7/9/20 10:04 PM, Cong Wang wrote:
> On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
> wrote:
>>
>>
>>
>> On 7/8/20 1:24 PM, Cong Wang wrote:
>>> On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
>>> wrote:
The key is to avoid classifying packets from a same flow into different
class
On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> IOW, without these *additional* efforts, it is broken in terms of
> out-of-order.
>
Take a look at fq_codel, it provides a hash function for flow classification,
fq_codel_hash(), as default, thus its default configuration does not
have such issue
On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
wrote:
>
>
>
> On 7/8/20 1:24 PM, Cong Wang wrote:
> > On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
> > wrote:
> >>
> >> The key is to avoid classifying packets from a same flow into different
> >> classes. So we use socket priority to classify packet
On 7/8/20 1:24 PM, Cong Wang wrote:
> On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
> wrote:
>>
>> The key is to avoid classifying packets from a same flow into different
>> classes. So we use socket priority to classify packets. It's always going to
>> be correctly classified.
>>
>> Not sure
On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
wrote:
>
> The key is to avoid classifying packets from a same flow into different
> classes. So we use socket priority to classify packets. It's always going to
> be correctly classified.
>
> Not sure what do you mean by default configuration. But we
On 7/7/20 1:06 PM, Cong Wang wrote:
> On Mon, Jul 6, 2020 at 1:34 PM YU, Xiangning
> wrote:
>>
>>
>>
>> On 7/6/20 1:10 PM, Cong Wang wrote:
>>> On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
>>> wrote:
+static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
*root_l
On Mon, Jul 6, 2020 at 1:34 PM YU, Xiangning
wrote:
>
>
>
> On 7/6/20 1:10 PM, Cong Wang wrote:
> > On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
> > wrote:
> >> +static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
> >> *root_lock,
> >> + struct sk_buff
Hi Xiangning",
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/YU-Xiangning/Lockless-Token-Bucket-LTB-Qdisc/20200707-020918
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
On 7/6/20 1:29 PM, David Miller wrote:
> From: "YU, Xiangning"
> Date: Tue, 07 Jul 2020 02:08:13 +0800
>
>> Lockless Token Bucket (LTB) is a qdisc implementation that controls the
>> use of outbound bandwidth on a shared link. With the help of lockless
>> qdisc, and by decoupling rate limiting
On 7/6/20 1:10 PM, Cong Wang wrote:
> On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
> wrote:
>> +static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
>> *root_lock,
>> + struct sk_buff **to_free)
>> +{
>> + struct ltb_sched *ltb = qdisc_priv(sch)
From: "YU, Xiangning"
Date: Tue, 07 Jul 2020 02:08:13 +0800
> Lockless Token Bucket (LTB) is a qdisc implementation that controls the
> use of outbound bandwidth on a shared link. With the help of lockless
> qdisc, and by decoupling rate limiting and bandwidth sharing, LTB is
> designed to scale
On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
wrote:
> +static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
> *root_lock,
> + struct sk_buff **to_free)
> +{
> + struct ltb_sched *ltb = qdisc_priv(sch);
> + struct ltb_pcpu_sched *pcpu_q;
> +
On 7/6/20 11:37 AM, Stephen Hemminger wrote:
> On Tue, 07 Jul 2020 02:08:13 +0800
> "YU, Xiangning" wrote:
>
>> +static inline int ltb_drain(struct ltb_class *cl)
>> +{
>> +typeof(&cl->drain_queue) queue;
>> +struct sk_buff *skb;
>> +int npkts, bytes;
>> +unsigned long now = NO
On Tue, 07 Jul 2020 02:08:13 +0800
"YU, Xiangning" wrote:
> +static inline int ltb_drain(struct ltb_class *cl)
> +{
> + typeof(&cl->drain_queue) queue;
> + struct sk_buff *skb;
> + int npkts, bytes;
> + unsigned long now = NOW();
> + int cpu;
> + struct ltb_sched *ltb = qd
On Tue, 07 Jul 2020 02:08:13 +0800
"YU, Xiangning" wrote:
> +static inline s64 get_linkspeed(struct net_device *dev)
This is not performance sensitive and should not be marked inline.
> +{
> + struct ethtool_link_ksettings ecmd;
> +
> + ASSERT_RTNL();
> + if (netif_running(dev) &&
Lockless Token Bucket (LTB) is a qdisc implementation that controls the
use of outbound bandwidth on a shared link. With the help of lockless
qdisc, and by decoupling rate limiting and bandwidth sharing, LTB is
designed to scale in the cloud data centers.
Signed-off-by: Xiangning Yu
---
include/
21 matches
Mail list logo
