On Wed, 9 Aug 2023 11:23:42 +0200 Laurent Vivier <lvivier(a)redhat.com> wrote:The number of items in pool_l4_t is defined to UIO_MAXIOV, not TAP_SEQS. TAP_SEQS is the number of the messages....sequences of packets (within the same connection), rather than "messages" (which might sound like packets).Fix the value used to compare seq->p.count with. Fix: bb708111833e ("treewide: Packet abstraction with mandatory boundary checks") Signed-off-by: Laurent Vivier <lvivier(a)redhat.com>I was wondering why throughput tests on the tap path, namespace to host, started failing miserably with this (0.4 Gbps instead of 7 Gbps with small packets). It turned out that yes, the pool has UIO_MAXIOV items, but (also by mistake in some sense) we initialised only the first TAP_SEQS ones. This fixes it: diff --git a/tap.c b/tap.c index 7d5dd6a..a6f8692 100644 --- a/tap.c +++ b/tap.c @@ -1258,8 +1258,8 @@ void tap_sock_init(struct ctx *c) pool_tap6_storage = PACKET_INIT(pool_tap6, TAP_MSGS, pkt_buf, sz); for (i = 0; i < TAP_SEQS; i++) { - tap4_l4[i].p = PACKET_INIT(pool_l4, TAP_SEQS, pkt_buf, sz); - tap6_l4[i].p = PACKET_INIT(pool_l4, TAP_SEQS, pkt_buf, sz); + tap4_l4[i].p = PACKET_INIT(pool_l4, UIO_MAXIOV, pkt_buf, sz); + tap6_l4[i].p = PACKET_INIT(pool_l4, UIO_MAXIOV, pkt_buf, sz); } if (c->fd_tap != -1) { /* Passed as --fd */ ...I would simply apply it on top. -- Stefano