netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: John Ousterhout <ouster@cs.stanford.edu>
Cc: Stephen Hemminger <stephen@networkplumber.org>, netdev@vger.kernel.org
Subject: Re: Upstream Homa?
Date: Fri, 11 Nov 2022 20:25:44 +0100	[thread overview]
Message-ID: <Y26huGkf50zPPCmf@lunn.ch> (raw)
In-Reply-To: <CAGXJAmw=NY17=6TnDh0oV9WTmNkQCe9Q9F3Z=uGjG9x5NKn7TQ@mail.gmail.com>

On Fri, Nov 11, 2022 at 10:59:58AM -0800, John Ousterhout wrote:
> The netlink and 32-bit kernel issues are new for me; I've done some digging to
> learn more, but still have some questions.
> 

> * Is the intent that netlink replaces *all* uses of /proc and ioctl? Homa
> currently uses ioctls on sockets for I/O (its APIs aren't sockets-compatible).
> It looks like switching to netlink would double the number of system calls that
> have to be invoked, which would be unfortunate given Homa's goal of getting the
> lowest possible latency. It also looks like netlink might be awkward for
> dumping large volumes of kernel data to user space (potential for buffer
> overflow?).

I've not looked at the actually code, i'm making general comments.

netlink, like ioctl, is meant for the control plain, not the data
plain. Your statistics should be reported via netlink, for
example. netlink is used to configure routes, setup bonding, bridges
etc. netlink can also dump large volumes of data, it has no problems
dumping the full Internet routing table for example.

How you get real packet data between the userspace and kernel space is
a different question. You say it is not BSD socket compatible. But
maybe there is another existing kernel API which will work? Maybe post
what your ideal API looks like and why sockets don't work. Eric
Dumazet could give you some ideas about what the kernel has which
might do what you need. This is the uAPI point that Stephen raised.

> * By "32 bit kernel problems" are you referring to the lack of atomic 64-bit
> operations and using the facilities of u64_stats_sync.h, or is there a more
> general issue with 64-bit operations?

Those helpers do the real work, and should optimise to pretty much
nothing on an 64 bit kernel, but do the right thing on 32 bit kernels.

But you are right, the general point is that they are not atomic, so
you need to be careful with threads, and any access to a 64 bit values
needs to be protected somehow, hopefully in a way that is optimised
out on 64bit systems.

      Andrew

  parent reply	other threads:[~2022-11-11 19:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 19:42 Upstream Homa? John Ousterhout
2022-11-10 21:25 ` Stephen Hemminger
2022-11-10 23:23   ` Andrew Lunn
     [not found]     ` <CAGXJAmw=NY17=6TnDh0oV9WTmNkQCe9Q9F3Z=uGjG9x5NKn7TQ@mail.gmail.com>
2022-11-11 19:10       ` Stephen Hemminger
2022-11-11 19:25       ` Andrew Lunn [this message]
2022-11-12  7:53         ` Jiri Pirko
2022-11-13  6:25           ` John Ousterhout
2022-11-13 17:10             ` Andrew Lunn
2022-11-13 20:10               ` John Ousterhout
2022-11-13 20:37                 ` Andrew Lunn
2022-11-14  5:37                   ` John Ousterhout
2022-11-13  6:09         ` John Ousterhout
2022-11-13  8:24           ` Jiri Pirko
2022-11-13 18:53             ` Andrew Lunn
2022-12-04 18:17 ` Jamal Hadi Salim

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y26huGkf50zPPCmf@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --cc=ouster@cs.stanford.edu \
    --cc=stephen@networkplumber.org \
    /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;
as well as URLs for NNTP newsgroup(s).