From: Paolo Abeni <pabeni@redhat.com>
To: John Ousterhout <ouster@cs.stanford.edu>, netdev@vger.kernel.org
Cc: edumazet@google.com, horms@kernel.org, kuba@kernel.org
Subject: Re: [PATCH net-next v15 05/15] net: homa: create homa_peer.h and homa_peer.c
Date: Tue, 26 Aug 2025 11:32:57 +0200 [thread overview]
Message-ID: <66dff631-3f6d-4a7c-b0f2-627c25c49967@redhat.com> (raw)
In-Reply-To: <20250818205551.2082-6-ouster@cs.stanford.edu>
On 8/18/25 10:55 PM, John Ousterhout wrote:
> +/**
> + * homa_peer_rcu_callback() - This function is invoked as the callback
> + * for an invocation of call_rcu. It just marks a peertab to indicate that
> + * it was invoked.
> + * @head: Contains information used to locate the peertab.
> + */
> +void homa_peer_rcu_callback(struct rcu_head *head)
> +{
> + struct homa_peertab *peertab;
> +
> + peertab = container_of(head, struct homa_peertab, rcu_head);
> + atomic_set(&peertab->call_rcu_pending, 0);
> +}
The free schema is quite convoluted and different from the usual RCU
handling. Why don't you simply call_rcu() on the given peer once that
the refcount reaches zero?
> +
> +/**
> + * homa_peer_free_dead() - Release peers on peertab->dead_peers
> + * if possible.
> + * @peertab: Check the dead peers here.
> + */
> +void homa_peer_free_dead(struct homa_peertab *peertab)
> + __must_hold(peertab->lock)
> +{
> + struct homa_peer *peer, *tmp;
> +
> + /* A dead peer can be freed only if:
> + * (a) there are no call_rcu calls pending (if there are, it's
> + * possible that a new reference might get created for the
> + * peer)
> + * (b) the peer's reference count is zero.
> + */
> + if (atomic_read(&peertab->call_rcu_pending))
> + return;
> + list_for_each_entry_safe(peer, tmp, &peertab->dead_peers, dead_links) {
> + if (atomic_read(&peer->refs) == 0) {
> + list_del_init(&peer->dead_links);
> + homa_peer_free(peer);
> + }
> + }
> +}
> +
> +/**
> + * homa_peer_wait_dead() - Don't return until all of the dead peers have
> + * been freed.
> + * @peertab: Overall information about peers, which includes a dead list.
> + *
> + */
> +void homa_peer_wait_dead(struct homa_peertab *peertab)
> +{
> + while (1) {
> + spin_lock_bh(&peertab->lock);
> + homa_peer_free_dead(peertab);
> + if (list_empty(&peertab->dead_peers)) {
> + spin_unlock_bh(&peertab->lock);
> + return;
> + }
> + spin_unlock_bh(&peertab->lock);
> + }
> +}
Apparently unused.
> +/**
> + * homa_dst_refresh() - This method is called when the dst for a peer is
> + * obsolete; it releases that dst and creates a new one.
> + * @peertab: Table containing the peer.
> + * @peer: Peer whose dst is obsolete.
> + * @hsk: Socket that will be used to transmit data to the peer.
> + */
> +void homa_dst_refresh(struct homa_peertab *peertab, struct homa_peer *peer,
> + struct homa_sock *hsk)
> +{
> + struct dst_entry *dst;
> +
> + dst = homa_peer_get_dst(peer, hsk);
> + if (IS_ERR(dst))
> + return;
> + dst_release(peer->dst);
> + peer->dst = dst;
Why the above does not need any lock? Can multiple RPC race on the same
peer concurrently?
> +/**
> + * struct homa_peer - One of these objects exists for each machine that we
> + * have communicated with (either as client or server).
> + */
> +struct homa_peer {
> + /** @ht_key: The hash table key for this peer in peertab->ht. */
> + struct homa_peer_key ht_key;
> +
> + /**
> + * @ht_linkage: Used by rashtable implement to link this peer into
> + * peertab->ht.
> + */
> + struct rhash_head ht_linkage;
> +
> + /** @dead_links: Used to link this peer into peertab->dead_peers. */
> + struct list_head dead_links;
> +
> + /**
> + * @refs: Number of unmatched calls to homa_peer_hold; it's not safe
> + * to free this object until the reference count is zero.
> + */
> + atomic_t refs ____cacheline_aligned_in_smp;
Please use refcount_t instead.
> +/**
> + * homa_peer_hash() - Hash function used for @peertab->ht.
> + * @data: Pointer to key for which a hash is desired. Must actually
> + * be a struct homa_peer_key.
> + * @dummy: Not used
> + * @seed: Seed for the hash.
> + * Return: A 32-bit hash value for the given key.
> + */
> +static inline u32 homa_peer_hash(const void *data, u32 dummy, u32 seed)
> +{
> + /* This is MurmurHash3, used instead of the jhash default because it
> + * is faster (25 ns vs. 40 ns as of May 2025).
> + */
> + BUILD_BUG_ON(sizeof(struct homa_peer_key) & 0x3);
It's likely worthy to place the hash function implementation in a
standalone header.
> + const u32 len = sizeof(struct homa_peer_key) >> 2;
> + const u32 c1 = 0xcc9e2d51;
> + const u32 c2 = 0x1b873593;
> + const u32 *key = data;
> + u32 h = seed;
> +
> + for (size_t i = 0; i < len; i++) {
> + u32 k = key[i];
> +
> + k *= c1;
> + k = (k << 15) | (k >> (32 - 15));
> + k *= c2;
> +
> + h ^= k;
> + h = (h << 13) | (h >> (32 - 13));
> + h = h * 5 + 0xe6546b64;
> + }
> +
> + h ^= len * 4; // Total number of input bytes
Please avoid C99 comments
/P
next prev parent reply other threads:[~2025-08-26 9:33 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 20:55 [PATCH net-next v15 00/15] Begin upstreaming Homa transport protocol John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 01/15] net: homa: define user-visible API for Homa John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 02/15] net: homa: create homa_wire.h John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 03/15] net: homa: create shared Homa header files John Ousterhout
2025-08-26 9:05 ` Paolo Abeni
2025-08-26 23:10 ` John Ousterhout
2025-08-27 7:21 ` Paolo Abeni
2025-08-29 3:03 ` John Ousterhout
2025-08-29 7:53 ` Paolo Abeni
2025-08-29 17:08 ` John Ousterhout
2025-09-01 7:59 ` Paolo Abeni
2025-08-27 12:16 ` Eric Dumazet
2025-08-18 20:55 ` [PATCH net-next v15 04/15] net: homa: create homa_pool.h and homa_pool.c John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 05/15] net: homa: create homa_peer.h and homa_peer.c John Ousterhout
2025-08-26 9:32 ` Paolo Abeni [this message]
2025-08-27 23:27 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 06/15] net: homa: create homa_sock.h and homa_sock.c John Ousterhout
2025-08-26 10:10 ` Paolo Abeni
2025-08-31 23:29 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 07/15] net: homa: create homa_interest.h and homa_interest.c John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 08/15] net: homa: create homa_pacer.h and homa_pacer.c John Ousterhout
2025-08-26 10:53 ` Paolo Abeni
2025-09-01 16:35 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 09/15] net: homa: create homa_rpc.h and homa_rpc.c John Ousterhout
2025-08-26 11:31 ` Paolo Abeni
2025-09-01 20:10 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 10/15] net: homa: create homa_outgoing.c John Ousterhout
2025-08-26 11:50 ` Paolo Abeni
2025-09-01 20:21 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 11/15] net: homa: create homa_utils.c John Ousterhout
2025-08-26 11:52 ` Paolo Abeni
2025-09-01 20:30 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 12/15] net: homa: create homa_incoming.c John Ousterhout
2025-08-26 12:05 ` Paolo Abeni
2025-09-01 22:12 ` John Ousterhout
2025-09-02 7:19 ` Eric Dumazet
2025-08-18 20:55 ` [PATCH net-next v15 13/15] net: homa: create homa_timer.c John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 14/15] net: homa: create homa_plumbing.c John Ousterhout
2025-08-26 16:17 ` Paolo Abeni
2025-09-01 22:53 ` John Ousterhout
2025-09-01 23:03 ` Andrew Lunn
2025-09-02 4:54 ` John Ousterhout
2025-09-02 8:12 ` Paolo Abeni
2025-09-02 23:15 ` John Ousterhout
2025-08-18 20:55 ` [PATCH net-next v15 15/15] net: homa: create Makefile and Kconfig John Ousterhout
2025-08-23 5:36 ` kernel test robot
2025-08-22 15:51 ` [PATCH net-next v15 00/15] Begin upstreaming Homa transport protocol John Ousterhout
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=66dff631-3f6d-4a7c-b0f2-627c25c49967@redhat.com \
--to=pabeni@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ouster@cs.stanford.edu \
/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).