Re: [Cake] Cake implementations

["Toke Høiland-Jørgensen" <thoiland@redhat.com>]

"Adam Moffett" <adam@plexicomm.net> writes:

>>
>>>  Second concern is that many of our equipment vendors already use
>>>  Linux. Even Cisco now in some products. Maybe we'll waste our time
>>>  trying to roll our own solution and then find that a software update
>>>  from a vendor next year gives us everything we needed anyway.
>>
>>This would be great, of course, and do go and bug your vendors to solve
>>this problem! Note, however, that just because a system is running
>>Linux on the control plane, it may be using a hardware-offloaded data
>>plane that does not have any of the bufferbloat mitigation features
>>(unless the vendor specifically implemented them). I'm hoping that
>>*eventually* these things will be ubiquitous across the industry, but
>>thus far this has seemed to be an "any decade now" kind of proposition :/
>>
>>-Toke
> That's a great point.
>
> Is the software more or less CPU independent? Would we run into any 
> known problems with a 72-core Tilera platform?

Hmm, well, maybe? Depends on the networking hardware; you can run a
separate qdisc on each hardware queue on your network adapter. So if you
can configure that for enough queues you can scale to all 72 cores.
Otherwise, you'll get lock contention between cores trying to transmit
on the same hardware queue, in which case the best solution may be to
configure packet steering so you're just not using all cores.

Jesper's script that I linked previously is basically a way to program
this steering. So it should be doable, but some care is needed in
designing the system.

> Thanks for all your help and input by the way.

You're very welcome! It's always great to hear from someone who is aware
of (and wants to fix!) bufferbloat in their network :)

-Toke