public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Laurent Vivier <lvivier@redhat.com>, passt-dev@passt.top
Subject: Re: [PATCH v5 3/8] tap: refactor packets handling functions
Date: Wed, 12 Jun 2024 08:34:21 +0200	[thread overview]
Message-ID: <20240612083408.43fffc4f@elisabeth> (raw)
In-Reply-To: <Zmk905L9LwBrYc5h@zatzit>

On Wed, 12 Jun 2024 16:18:59 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Wed, Jun 12, 2024 at 12:09:50AM +0200, Stefano Brivio wrote:
> > On Wed,  5 Jun 2024 17:21:24 +0200
> > Laurent Vivier <lvivier@redhat.com> wrote:
> >   
> > > Consolidate pool_tap4() and pool_tap6() into pool_flush_all(),
> > > and tap4_handler() and tap6_handler() into tap_handler_all().
> > > Create a generic packet_add_all() to consolidate packet
> > > addition logic and reduce code duplication.
> > > 
> > > The purpose is to ease the export of these functions to use
> > > them with the vhost-user backend.
> > > 
> > > Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> > > ---
> > >  tap.c | 113 +++++++++++++++++++++++++++++++++-------------------------
> > >  tap.h |   7 ++++
> > >  2 files changed, 71 insertions(+), 49 deletions(-)
> > > 
> > > diff --git a/tap.c b/tap.c
> > > index 2ea08491a51f..5fb3cb83f3d2 100644
> > > --- a/tap.c
> > > +++ b/tap.c
> > > @@ -920,6 +920,61 @@ append:
> > >  	return in->count;
> > >  }
> > >  
> > > +/**
> > > + * pool_flush() - Flush both IPv4 and IPv6 packet pools
> > > + */
> > > +void pool_flush_all(void)
> > > +{
> > > +	pool_flush(pool_tap4);
> > > +	pool_flush(pool_tap6);
> > > +}
> > > +
> > > +/**
> > > + * tap_handler_all() - IPv4/IPv4 and ARP packet handler for tap file descriptor  
> > 
> > IPv4/IPv6
> >   
> > > + * @c:		Execution context
> > > + * @now:	Current timestamp
> > > + */
> > > +void tap_handler_all(struct ctx *c, const struct timespec *now)  
> > 
> > I wonder if this shouldn't be named tap_handler() instead. As we
> > already have tap_handler_passt() and tap_handler_pasta(), it's not
> > immediately clear what "all" refers to.  
> 
> I concur, I think tap_handler() is a better name.
> 
> > > +{
> > > +	tap4_handler(c, pool_tap4, now);
> > > +	tap6_handler(c, pool_tap6, now);
> > > +}
> > > +
> > > +/**
> > > + * packet_add_all_do() - Add a packet to the appropriate TAP pool  
> > 
> > A couple of remarks here:
> > 
> > - it's a bit unexpected that this is still in tap.c (it adds packets to
> >   a pool, it should be in packet.c judging by this name/description).
> >   If we call it tap_queue_packet(), then it probably makes more sense?
> > 
> > - this does more than adding a packet to a pool. It's probably useless
> >   to describe in detail what this does, as the function body is anyway
> >   rather short and clear, but the current description could be a bit
> >   misleading. What about "Queue/capture packet, update notion of
> >   guest MAC address"?  
> 
> So, given this, I think it does make more sense for this to be in
> tap.c than packet.c.  How about calling it tap_add_packets().

It's a single packet it adds, so perhaps tap_add_packet()?

> > - what happens if you just call packet_add() from here, without dealing
> >   with 'func' and 'line'? I think it's fine to print in tracing output
> >   name and lines from this function, instead of the ones from the
> >   caller. It's obvious who the caller is  
> 
> It is as of this patch, but I believe the idea is this will also be
> called from VU code down the line.

Okay, but even then, it would be obvious from previous tracing output
who the caller is. What's relevant here is to log that something went
wrong while adding a packet to an IPv4 or IPv6 pool. I don't think we
should bother passing around function name and line to log anything
else.

> > > + * @c:		Execution context
> > > + * @l2len:	Total L2 packet length
> > > + * @p:		Packet buffer
> > > + * @func:	For tracing: name of calling function, NULL means no trace()
> > > + * @line:	For tracing: caller line of function call
> > > + */
> > > +void packet_add_all_do(struct ctx *c, ssize_t l2len, char *p,
> > > +		       const char *func, int line)
> > > +{
> > > +	const struct ethhdr *eh;
> > > +
> > > +	pcap(p, l2len);
> > > +
> > > +	eh = (struct ethhdr *)p;
> > > +
> > > +	if (memcmp(c->mac_guest, eh->h_source, ETH_ALEN)) {
> > > +		memcpy(c->mac_guest, eh->h_source, ETH_ALEN);
> > > +		proto_update_l2_buf(c->mac_guest, NULL);
> > > +	}
> > > +
> > > +	switch (ntohs(eh->h_proto)) {
> > > +	case ETH_P_ARP:
> > > +	case ETH_P_IP:
> > > +		packet_add_do(pool_tap4, l2len, p, func, line);
> > > +		break;
> > > +	case ETH_P_IPV6:
> > > +		packet_add_do(pool_tap6, l2len, p, func, line);
> > > +		break;
> > > +	default:
> > > +		break;
> > > +	}
> > > +}
> > > +
> > >  /**
> > >   * tap_sock_reset() - Handle closing or failure of connect AF_UNIX socket
> > >   * @c:		Execution context
> > > @@ -946,7 +1001,6 @@ static void tap_sock_reset(struct ctx *c)
> > >  void tap_handler_passt(struct ctx *c, uint32_t events,
> > >  		       const struct timespec *now)
> > >  {
> > > -	const struct ethhdr *eh;
> > >  	ssize_t n, rem;
> > >  	char *p;
> > >  
> > > @@ -959,8 +1013,7 @@ redo:
> > >  	p = pkt_buf;
> > >  	rem = 0;
> > >  
> > > -	pool_flush(pool_tap4);
> > > -	pool_flush(pool_tap6);
> > > +	pool_flush_all();
> > >  
> > >  	n = recv(c->fd_tap, p, TAP_BUF_FILL, MSG_DONTWAIT);
> > >  	if (n < 0) {
> > > @@ -987,38 +1040,18 @@ redo:
> > >  		/* Complete the partial read above before discarding a malformed
> > >  		 * frame, otherwise the stream will be inconsistent.
> > >  		 */
> > > -		if (l2len < (ssize_t)sizeof(*eh) ||
> > > +		if (l2len < (ssize_t)sizeof(struct ethhdr) ||
> > >  		    l2len > (ssize_t)ETH_MAX_MTU)
> > >  			goto next;
> > >  
> > > -		pcap(p, l2len);
> > > -
> > > -		eh = (struct ethhdr *)p;
> > > -
> > > -		if (memcmp(c->mac_guest, eh->h_source, ETH_ALEN)) {
> > > -			memcpy(c->mac_guest, eh->h_source, ETH_ALEN);
> > > -			proto_update_l2_buf(c->mac_guest, NULL);
> > > -		}
> > > -
> > > -		switch (ntohs(eh->h_proto)) {
> > > -		case ETH_P_ARP:
> > > -		case ETH_P_IP:
> > > -			packet_add(pool_tap4, l2len, p);
> > > -			break;
> > > -		case ETH_P_IPV6:
> > > -			packet_add(pool_tap6, l2len, p);
> > > -			break;
> > > -		default:
> > > -			break;
> > > -		}
> > > +		packet_add_all(c, l2len, p);
> > >  
> > >  next:
> > >  		p += l2len;
> > >  		n -= l2len;
> > >  	}
> > >  
> > > -	tap4_handler(c, pool_tap4, now);
> > > -	tap6_handler(c, pool_tap6, now);
> > > +	tap_handler_all(c, now);
> > >  
> > >  	/* We can't use EPOLLET otherwise. */
> > >  	if (rem)
> > > @@ -1043,35 +1076,18 @@ void tap_handler_pasta(struct ctx *c, uint32_t events,
> > >  redo:
> > >  	n = 0;
> > >  
> > > -	pool_flush(pool_tap4);
> > > -	pool_flush(pool_tap6);
> > > +	pool_flush_all();
> > >  restart:
> > >  	while ((len = read(c->fd_tap, pkt_buf + n, TAP_BUF_BYTES - n)) > 0) {
> > > -		const struct ethhdr *eh = (struct ethhdr *)(pkt_buf + n);
> > >  
> > > -		if (len < (ssize_t)sizeof(*eh) || len > (ssize_t)ETH_MAX_MTU) {
> > > +		if (len < (ssize_t)sizeof(struct ethhdr) ||
> > > +		    len > (ssize_t)ETH_MAX_MTU) {
> > >  			n += len;
> > >  			continue;
> > >  		}
> > >  
> > > -		pcap(pkt_buf + n, len);
> > >  
> > > -		if (memcmp(c->mac_guest, eh->h_source, ETH_ALEN)) {
> > > -			memcpy(c->mac_guest, eh->h_source, ETH_ALEN);
> > > -			proto_update_l2_buf(c->mac_guest, NULL);
> > > -		}
> > > -
> > > -		switch (ntohs(eh->h_proto)) {
> > > -		case ETH_P_ARP:
> > > -		case ETH_P_IP:
> > > -			packet_add(pool_tap4, len, pkt_buf + n);
> > > -			break;
> > > -		case ETH_P_IPV6:
> > > -			packet_add(pool_tap6, len, pkt_buf + n);
> > > -			break;
> > > -		default:
> > > -			break;
> > > -		}
> > > +		packet_add_all(c, len, pkt_buf + n);
> > >  
> > >  		if ((n += len) == TAP_BUF_BYTES)
> > >  			break;
> > > @@ -1082,8 +1098,7 @@ restart:
> > >  
> > >  	ret = errno;
> > >  
> > > -	tap4_handler(c, pool_tap4, now);
> > > -	tap6_handler(c, pool_tap6, now);
> > > +	tap_handler_all(c, now);
> > >  
> > >  	if (len > 0 || ret == EAGAIN)
> > >  		return;
> > > diff --git a/tap.h b/tap.h
> > > index 2285a87093f9..3ffb7d6c3a91 100644
> > > --- a/tap.h
> > > +++ b/tap.h
> > > @@ -70,5 +70,12 @@ void tap_handler_passt(struct ctx *c, uint32_t events,
> > >  		       const struct timespec *now);
> > >  int tap_sock_unix_open(char *sock_path);
> > >  void tap_sock_init(struct ctx *c);
> > > +void pool_flush_all(void);
> > > +void tap_handler_all(struct ctx *c, const struct timespec *now);
> > > +
> > > +void packet_add_all_do(struct ctx *c, ssize_t l2len, char *p,
> > > +		       const char *func, int line);
> > > +#define packet_add_all(p, l2len, start)					\
> > > +	packet_add_all_do(p, l2len, start, __func__, __LINE__)
> > >  
> > >  #endif /* TAP_H */  
> >   
> 

-- 
Stefano


  reply	other threads:[~2024-06-12  6:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05 15:21 [PATCH v5 0/8] Add vhost-user support to passt (part 2) Laurent Vivier
2024-06-05 15:21 ` [PATCH v5 1/8] tcp: extract buffer management from tcp_send_flag() Laurent Vivier
2024-06-11  5:31   ` David Gibson
2024-06-11 11:42     ` Laurent Vivier
2024-06-12  6:31       ` David Gibson
2024-06-11 22:09   ` Stefano Brivio
2024-06-12  6:32     ` David Gibson
2024-06-05 15:21 ` [PATCH v5 2/8] tcp: move buffers management functions to their own file Laurent Vivier
2024-06-11 22:09   ` Stefano Brivio
2024-06-12  6:14   ` David Gibson
2024-06-12 12:03     ` Stefano Brivio
2024-06-05 15:21 ` [PATCH v5 3/8] tap: refactor packets handling functions Laurent Vivier
2024-06-11 22:09   ` Stefano Brivio
2024-06-12  6:18     ` David Gibson
2024-06-12  6:34       ` Stefano Brivio [this message]
2024-06-12  6:37         ` David Gibson
2024-06-12  6:21   ` David Gibson
2024-06-05 15:21 ` [PATCH v5 4/8] udp: refactor UDP header update functions Laurent Vivier
2024-06-11 22:10   ` Stefano Brivio
2024-06-12  6:27   ` David Gibson
2024-06-05 15:21 ` [PATCH v5 5/8] udp: rename udp_sock_handler() to udp_buf_sock_handler() Laurent Vivier
2024-06-12  6:28   ` David Gibson
2024-06-05 15:21 ` [PATCH v5 6/8] vhost-user: compare mode MODE_PASTA and not MODE_PASST Laurent Vivier
2024-06-11 22:10   ` Stefano Brivio
2024-06-05 15:21 ` [PATCH v5 7/8] iov: remove iov_copy() Laurent Vivier
2024-06-05 15:21 ` [PATCH v5 8/8] tap: use in->buf_size rather than sizeof(pkt_buf) Laurent Vivier

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=20240612083408.43fffc4f@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).