From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v5 01/29] arp: Don't mix incoming and outgoing buffers
Date: Mon, 26 May 2025 16:18:55 +0200 [thread overview]
Message-ID: <20250526161846.658537f4@elisabeth> (raw)
In-Reply-To: <20250417165136.2688884-2-lvivier@redhat.com>
Here's my review, finally. Apologies for the very substantial delay.
On Thu, 17 Apr 2025 18:51:08 +0200
Laurent Vivier <lvivier@redhat.com> wrote:
> Don't use the memory of the incoming packet to build the outgoing buffer
> as it can be memory of the TX queue in the case of vhost-user.
>
> Moreover with vhost-user, the packet can be splitted accross several
> iovec and it's easier to rebuild it in a buffer than updating an
> existing iovec array.
>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arp.c | 84 ++++++++++++++++++++++++++++++++++++++---------------------
> 1 file changed, 55 insertions(+), 29 deletions(-)
>
> diff --git a/arp.c b/arp.c
> index fc482bbd9938..9d68d7c3b602 100644
> --- a/arp.c
> +++ b/arp.c
> @@ -31,56 +31,82 @@
> #include "tap.h"
>
> /**
> - * arp() - Check if this is a supported ARP message, reply as needed
> + * ignore_arp() - Check if this is a supported ARP message
> * @c: Execution context
> - * @p: Packet pool, single packet with Ethernet buffer
> + * @ah: ARP header
> + * @am: ARP message
> *
> - * Return: 1 if handled, -1 on failure
> + * Return: true if the message is supported, false otherwise.
I find this, in combination with the name, a bit confusing. You now
have ignore_arp() returning true if the ARP message should *not* be
ignored.
As this function is essentially a filter, rather than reversing the
return value, I'd rather reverse the name, say:
* accept_arp() - Check if we should accept this ARP message
> */
> -int arp(const struct ctx *c, const struct pool *p)
> +static bool ignore_arp(const struct ctx *c,
> + const struct arphdr *ah, const struct arpmsg *am)
> {
> - unsigned char swap[4];
> - struct ethhdr *eh;
> - struct arphdr *ah;
> - struct arpmsg *am;
> - size_t l2len;
> -
> - eh = packet_get(p, 0, 0, sizeof(*eh), NULL);
> - ah = packet_get(p, 0, sizeof(*eh), sizeof(*ah), NULL);
> - am = packet_get(p, 0, sizeof(*eh) + sizeof(*ah), sizeof(*am), NULL);
> -
> - if (!eh || !ah || !am)
> - return -1;
> -
> if (ah->ar_hrd != htons(ARPHRD_ETHER) ||
> ah->ar_pro != htons(ETH_P_IP) ||
> ah->ar_hln != ETH_ALEN ||
> ah->ar_pln != 4 ||
> ah->ar_op != htons(ARPOP_REQUEST))
> - return 1;
> + return true;
>
> /* Discard announcements, but not 0.0.0.0 "probes" */
> if (memcmp(am->sip, &in4addr_any, sizeof(am->sip)) &&
> !memcmp(am->sip, am->tip, sizeof(am->sip)))
> - return 1;
> + return true;
>
> /* Don't resolve the guest's assigned address, either. */
> if (!memcmp(am->tip, &c->ip4.addr, sizeof(am->tip)))
> + return true;
> +
> + return false;
> +}
> +
> +/**
> + * arp() - Check if this is a supported ARP message, reply as needed
> + * @c: Execution context
> + * @p: Packet pool, single packet with Ethernet buffer
> + *
> + * Return: 1 if handled, -1 on failure
> + */
> +int arp(const struct ctx *c, const struct pool *p)
> +{
> + struct {
> + struct ethhdr eh;
> + struct arphdr ah;
> + struct arpmsg am;
> + } __attribute__((__packed__)) resp;
> + const struct ethhdr *eh;
> + const struct arphdr *ah;
> + const struct arpmsg *am;
> +
> + eh = packet_get(p, 0, 0, sizeof(*eh), NULL);
> + ah = packet_get(p, 0, sizeof(*eh), sizeof(*ah), NULL);
> + am = packet_get(p, 0, sizeof(*eh) + sizeof(*ah), sizeof(*am), NULL);
> +
> + if (!eh || !ah || !am)
> + return -1;
> +
> + if (ignore_arp(c, ah, am))
> return 1;
>
> - ah->ar_op = htons(ARPOP_REPLY);
> - memcpy(am->tha, am->sha, sizeof(am->tha));
> - memcpy(am->sha, c->our_tap_mac, sizeof(am->sha));
> + /* ethernet header */
Nit: Ethernet
> + resp.eh.h_proto = htons(ETH_P_ARP);
> + memcpy(resp.eh.h_dest, eh->h_source, sizeof(resp.eh.h_dest));
> + memcpy(resp.eh.h_source, c->our_tap_mac, sizeof(resp.eh.h_source));
>
> - memcpy(swap, am->tip, sizeof(am->tip));
> - memcpy(am->tip, am->sip, sizeof(am->tip));
> - memcpy(am->sip, swap, sizeof(am->sip));
> + /* ARP header */
> + resp.ah.ar_op = htons(ARPOP_REPLY);
> + resp.ah.ar_hrd = ah->ar_hrd;
> + resp.ah.ar_pro = ah->ar_pro;
> + resp.ah.ar_hln = ah->ar_hln;
> + resp.ah.ar_pln = ah->ar_pln;
>
> - l2len = sizeof(*eh) + sizeof(*ah) + sizeof(*am);
> - memcpy(eh->h_dest, eh->h_source, sizeof(eh->h_dest));
> - memcpy(eh->h_source, c->our_tap_mac, sizeof(eh->h_source));
> + /* ARP message */
> + memcpy(resp.am.sha, c->our_tap_mac, sizeof(resp.am.sha));
> + memcpy(resp.am.sip, am->tip, sizeof(resp.am.sip));
> + memcpy(resp.am.tha, am->sha, sizeof(resp.am.tha));
> + memcpy(resp.am.tip, am->sip, sizeof(resp.am.tip));
>
> - tap_send_single(c, eh, l2len);
> + tap_send_single(c, &resp, sizeof(resp));
>
> return 1;
> }
--
Stefano
next prev parent reply other threads:[~2025-05-26 14:19 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 16:51 [PATCH v5 00/29] Introduce discontiguous frames management Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 01/29] arp: Don't mix incoming and outgoing buffers Laurent Vivier
2025-05-26 14:18 ` Stefano Brivio [this message]
2025-04-17 16:51 ` [PATCH v5 02/29] iov: Introduce iov_slice(), iov_tail_slice() and iov_tail_drop() Laurent Vivier
2025-05-26 14:19 ` Stefano Brivio
2025-05-26 15:20 ` Laurent Vivier
2025-06-02 13:35 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 03/29] iov: Update IOV_REMOVE_HEADER() and IOV_PEEK_HEADER() Laurent Vivier
2025-05-26 14:19 ` Stefano Brivio
2025-06-02 15:36 ` Laurent Vivier
2025-06-03 8:42 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 04/29] tap: Use iov_tail with tap_add_packet() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 05/29] packet: Use iov_tail with packet_add() Laurent Vivier
2025-05-26 14:19 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 06/29] packet: Add packet_data() Laurent Vivier
2025-05-26 14:19 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 07/29] arp: Convert to iov_tail Laurent Vivier
2025-05-26 14:19 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 08/29] ndp: " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 09/29] icmp: " Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 10/29] udp: " Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-05-26 15:47 ` Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 11/29] tcp: Convert tcp_tap_handler() to use iov_tail Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 12/29] tcp: Convert tcp_data_from_tap() " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 13/29] dhcpv6: move offset initialization out of dhcpv6_opt() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 14/29] dhcpv6: Extract sending of NotOnLink status Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 15/29] dhcpv6: Convert to iov_tail Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 16/29] dhcpv6: Use iov_tail in dhcpv6_opt() Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 17/29] dhcp: Convert to iov_tail Laurent Vivier
2025-05-26 14:20 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 18/29] ip: Use iov_tail in ipv6_l4hdr() Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 19/29] tap: Convert tap4_handler() to iov_tail Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 20/29] tap: Convert tap6_handler() " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 21/29] arp: use iov_tail rather than pool Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 22/29] dhcp: " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 23/29] dhcpv6: " Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 24/29] icmp: " Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 25/29] ndp: " Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 26/29] packet: remove PACKET_POOL() and PACKET_POOL_P() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 27/29] packet: remove unused parameter from PACKET_POOL_DECL() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 28/29] packet: add memory regions information into pool Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 29/29] packet: use buf to store iovec array Laurent Vivier
2025-05-26 14:21 ` Stefano Brivio
2025-05-27 13:16 ` Laurent Vivier
2025-06-02 13:35 ` Stefano Brivio
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=20250526161846.658537f4@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=lvivier@redhat.com \
--cc=passt-dev@passt.top \
/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.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
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 IMAP folder(s).