From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server-vie001.gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=new2025; t=1754012974; bh=8lCsY+EiSA7ZN9s9D89qIwv3OFHpH5sExSv9847rhD8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding:Message-ID:Date:From: Reply-To:Subject:To:Cc:In-Reply-To:References:Resent-Date: Resent-From:Resent-To:Resent-Cc:User-Agent:Content-Type: Content-Transfer-Encoding; b=apkMe/z4bMN0u7mvU8fIQbbieG3t83uIgq8xF+pnVscsDk6yFSJ6mH/uT3OgXvGab CR1McAhPpp6U95HuYn1SGp6J251Oy9qi3L0J5H6K2LS8Mu/se6eUcpOple5QOD3EZJ WY0DdGJUasANLMTtrY1pZqUXsC5yU34wm8p0kWoDi95LKRBQ0YCbJKYShb/hXv4qX5 QxW832DRZ8g1qVCr0M6DL+lnqPc+2H7Z2cExSbB0k9JiI89mWb4tfcNgBGbs0B5TFB otp7mWbrgVc7KMXKcS01mMoxa3FVgVb7M3jJ7ZaWwOmu4v01IUj5CqChwsb9FuwJYq DKD5lhPmghHoQ== Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by server-vie001.gnuweeb.org (Postfix) with ESMTPSA id 4BB883126F06 for ; Fri, 1 Aug 2025 01:49:34 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-55b8248e77bso1195620e87.2 for ; Thu, 31 Jul 2025 18:49:34 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCV89Xy0Jelb4gy750kq6sacBDgG8Zv5It1Kb48CMD2lKpE5kemtdDzR2dxXgUSWpcnBud62@vger.gnuweeb.org X-Gm-Message-State: AOJu0YwpoXTDMhILEccxdrDe2zXp1PiuPP2mHn3zKA1XDzyA2M/613eE 30URxMLJeApiHo6pBjIHrN+J77WZEP7kxZpYAQQl+xXeizG7oQ6YL3dCXgUzplvEx5K8BwS7V2S QH8Km23ZGZQgutopnnR8t/DexuVOOVt8= X-Google-Smtp-Source: AGHT+IFg8dJzph2oQopnuXKEgAzbj5rGcxs+ZK3NqEkPgmcpKGrhvxFph0bwNepqTkkoG63TKrKYmLgH976FgWJBkWU= X-Received: by 2002:a05:6512:ba7:b0:553:3916:4e1c with SMTP id 2adb3069b0e04-55b8f262b98mr226091e87.2.1754012973665; Thu, 31 Jul 2025 18:49:33 -0700 (PDT) MIME-Version: 1.0 References: <20250731030856.366368-1-reyuki@gnuweeb.org> In-Reply-To: From: reyuki Date: Fri, 1 Aug 2025 08:49:22 +0700 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXw5gZFNP35aIbHfQrTaCqSCadHtj_iuPwpI873UPVBnYcjgMf1AN1b247M Message-ID: Subject: Re: [PATCH gwproxy v1 0/3] Initial work for DNS lookup implementation To: Ammar Faizi Cc: Alviro Iskandar Setiawan , "GNU/Weeb Mailing List" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: On Thu, Jul 31, 2025 at 8:39=E2=80=AFPM Ammar Faizi wrote: > > On Thu, Jul 31, 2025 at 10:07:43AM +0700, Ahmad Gani wrote: >> Is it preferred to use the current model (spawning dedicated DNS threads= ) >> and make the behavior of the resolver the same as getaddrinfo (blocking)= ? >> So far I've created the addrinfo interfaces with C-ares style and tested >> it; although, it's still blocking. >> >> I would like to know the numbers for comparison between the thread model >> vs. the asynchronous model. Which approach is best for this scenario/cas= e >> (DNS resolution)? > > It's better if the DNS resolution can be done non-blocking via epoll > than a separate thread. > > With dedicated DNS worker threads, you need: > > 1) Queue. > 2) Mutex. > 3) Condvar. > 4) An evenfd to notify the sleeping epoll. > 5) A reference count to avoid UAF on cancellation. > 6) Open-and-close a SOCK_DGRAM for each query. > 7) eventfd_write() from the producer. > 8) eventfd_read() from the consumer (sleeping epoll). > > The steps to perform just a single query are unecessarily compilated. > The communication between multiple threads costs could have been elided > with a non-blocking pollable socket. > > With a non-blocking pollable socket, everything is done more efficiently: > > 1) No contention waiting on queue mutex lock. > 2) Only one SOCK_DGRAM socket is needed (can be reused forever). > 3) No event fd is needed. > 4) No mutex is not needed (maybe only for the cache, but even that, > it's very minimal with rwlock, not a full mutex protection). > > You can scale up the number of SOCK_DGRAM sockets if you ever want to > use multiple DNS servers. Anyway, since SOCK_DGRAM is stateless, you > can even use one SOCK_DGRAM to send-and-recv to-from multiple DNS > servers (see sendto(2) and recvfrom(2)). > > Also, with a very busy proxy server, you'll be more far away from > hitting RLIMIT_NOFILE as the number of fds is probably cut in half > (no event fd + socket fds created by getaddrinfo() internally). > >> I feel like multi-threading is much faster than single-threading, as it'= s >> executed in true parallel (on a multi-core system) compared to >> concurrently doing things with an event notification mechanism. > > Yes, but you should add more threads that call epoll_wait(). Not the > number of DNS threads. The reason why we have so many DNS threads is > because we can't poll it. Not because we have maxed out a CPU core to > 100%. > > For now, multithread makes things faster when performing getaddrinfo() > because multiple queries are done asynchronously. It's not because > getaddrinfo() calls have fully eaten your CPU core. Right? > > Ideally, the same thing could be achieved with epoll_wait() without > extra mutex, condvar and eventfd (which is cheaper). > > Communication between threads is costly, avoid it if possible. If you > can have multithreaded workload with zero communication between threads, > that's very good. And that's one of the reasons we want to invent our own > DNS resolver. It's an effort to reduce the communication between threads. Thanks for convincing me, now I can decide to use the polling option instea= d of blocking getaddrinfo option that's executed in dedicated threads. I think I get the general idea of using pollable socket: - mark the UDP socket as non block - let the caller have reference to the socket, so they can poll it But have difficulties in the technical implementation: When the caller is notified, they must call what? It is a UDP socket, it's said to be stateless, does connect can possibly return EINPROGRESS? It seems to be a common case in non-blocking TCP socket. And if EAGAIN is received from recv, do we retry from send? I find it unclear how the library and the program interact when using the non-blocking behavior, but I think I will give it a thought (maybe add an internal state to address these concerns). >> I also noticed that in the C-ares example [3], they recommend using the >> event thread example, and it is similar to the io_uring model in my >> perspective, where the operation is executed internally instead of >> letting the caller poll for readiness with ares_process_fd. Maybe we can >> mimic this aspect? > > That's wrong, io_uring arms poll for networking workloads, it does not > create io-wq threads (except for shutdown()). I didn't talk about io-wq threads; I don't have any technical understanding or knowledge about them. When I said 'the operation is executed internally,' what I meant was my general understanding of the io_uring model that tells of the completion of certain operations you've requested. which is different compared to the epoll model that tells readiness for a specific operation, and you execute that operation on your own. > https://discord.com/channels/1241076672589991966/1241076672589991970/1398= 781840546074624 I can't view the linked message from the given link, is it a private commun= ity? -- Ahmad Gani