From: dave seddon <dave.seddon.ca@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] cake at 8gbit
Date: Fri, 6 Dec 2024 15:43:17 -0800 [thread overview]
Message-ID: <CANypexQwc7OVZQWJU+SPdPg9ZfX6ucML+B4swhY_DDeMoC-BYg@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw6MdQkJXU=4E4QT6t6chDO__sv4dEPY5_A_FUW1xw1aHw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2102 bytes --]
Thanks again for this link. Super interesting.
Regarding monitoring socket performance with Kubernetes clusters, I've
actually been working on deploying the xTCP socket monitoring tool into
kubernetes clusters. The intention would be to stream the tcp_diag data
out of all the PoD on a regular basis.
The challenge is that ideally from a single process, you could open a
netlink socket into every PoD on the kubernetes node. This is not
possible, as far as I understand, because a process can only live in a
single name space at any given time.
e.g. You can't do this:
[image: image.png]
The simple solution would be too run many versions of xTCP as a "sidecar"
in each PoD, like this:
[image: image.png]
This isn't great because then xTCP would be duplicated many times, so it
would waste RAMs, and you would have lots of Kafka sockets streaming the
socket data out out each PoD.
An alternative I was thinking would be to possibly have a small unix domain
socket (UDS) to netlink proxy in each PoD. Over the UDS, the xTCP
daemonset ( single instance per node) could read and write the tcp_diag
data.
(e.g. I was thinking of a little rust binary that would essentially open a
UDS socket and a netlink socket, and then essentially copy from one to the
other. )
[image: image.png]
I don't really know if this is a good idea, or if I'm missing some other
way to extract the socket data from many PoDs. Happy to hear ideas please!
:)
Full xtCP slides, including these "xTCP for kubernetes" here:
https://docs.google.com/presentation/d/11rixKNfIBCdofUpPL2wOuiWJXa40x4I0A1wuTMMv4Uo/edit#slide=id.g31cb19b2f14_0_87
Thanks,
Dave Seddon
On Tue, Nov 19, 2024 at 8:07 AM Dave Taht via Cake <
cake@lists.bufferbloat.net> wrote:
> https://github.com/cilium/cilium/issues/29083#issuecomment-2485142294
>
> --
> Dave Täht CSO, LibreQos
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
--
Regards,
Dave Seddon
+1 415 857 5102
[-- Attachment #1.2: Type: text/html, Size: 3585 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 129740 bytes --]
[-- Attachment #3: image.png --]
[-- Type: image/png, Size: 183206 bytes --]
[-- Attachment #4: image.png --]
[-- Type: image/png, Size: 164177 bytes --]
prev parent reply other threads:[~2024-12-06 23:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 16:06 Dave Taht
2024-12-06 23:43 ` dave seddon [this message]
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANypexQwc7OVZQWJU+SPdPg9ZfX6ucML+B4swhY_DDeMoC-BYg@mail.gmail.com \
--to=dave.seddon.ca@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.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