From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3E15CA0547; Wed, 29 Sep 2021 12:04:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF95C410D7; Wed, 29 Sep 2021 12:04:09 +0200 (CEST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by mails.dpdk.org (Postfix) with ESMTP id 1D20F40E3C for ; Wed, 29 Sep 2021 12:04:08 +0200 (CEST) Received: by mail-ed1-f53.google.com with SMTP id l8so6569091edw.2 for ; Wed, 29 Sep 2021 03:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uEXxhX4oTN+/XnvD1rW9VHUcct3kZaJbdq0KDEBDQNg=; b=hNKTdOVdGvlfFgLSbelU19PWmpJvNZ4SUfa7a/pDKT318pxLN0TRQTG4A7QyPM7jsY PVaUUz62V2623G6kAMK48XiF9bif40dsIH34f57lW6l9qmU99V7CLoHz1r4/7jawAzOt 6Hbp2g6IU0PF0w/QPbwNRP2PsvzXlZGkpetYGU3uSyeBcQ0Yss+6F3UUZoDs/ZfGoJpO DOCUSGP/7vUJ0Tm81bS7PjgalEwgnqzsZtOhqcoKnFd/bJh4LAJzfBGUPzbp9BWtB3kJ 62ODVU2wlrhGlkNYpFFXVzPcRA8NqczmWza6EDtMHfRYESJuMl9OBbvLk70EgNp1sxuE bM+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uEXxhX4oTN+/XnvD1rW9VHUcct3kZaJbdq0KDEBDQNg=; b=tvqTf5dsBmNqyZI6jxJ56QUkV0gH7K96HfBb5rlr2OpQsNLOI2v6PtlBDx7HlMcglU 85gt/WIMoZgQHEVAhJT4lRts/ikrFwnk2qW/hvoErH1UzMKRng2tmbMV8J7XWG4b1AOW x26l8jllbJvRRXfGTuN3k9dgtNOUOkepFNdctA/68Ff9skAeSUDGKxwEcrYkOw33561Y rZQjdo4E+H+jWmS68o1YUeFSweyqjvgvkG/2uwpvhuR3yTR7n6LB+8CDhD1Q9bFptZuT JmGcTsw1uGIxQJtRjMyBlE++qZTA4r26joqZNpE0sDg6kvnx9CE/8uQXtDuEUfUBCo/7 L6lA== X-Gm-Message-State: AOAM530i9Qf677qC9Zf3OlWTTFZ7fkepT6g+tqnO55szurPlz15Vb6jp P7mwckaZdZRO8DIo8LITFGIiBpkuOv1PULevdWM= X-Google-Smtp-Source: ABdhPJxFnw56VFLvgOMHVvketII0f2JUQWXehPYGA3WTFzZUQdbGhf6JqZ9mJtGnCWZQZQL2Fk3/9Wghahe1lb7k21w= X-Received: by 2002:a17:906:b2cf:: with SMTP id cf15mr3901783ejb.111.1632909847710; Wed, 29 Sep 2021 03:04:07 -0700 (PDT) MIME-Version: 1.0 References: <1629466761-127333-1-git-send-email-tudor.cornea@gmail.com> <1631540746-38443-1-git-send-email-tudor.cornea@gmail.com> <9ec3e2cb-412a-a48b-2567-7e5ad6b1153f@intel.com> In-Reply-To: <9ec3e2cb-412a-a48b-2567-7e5ad6b1153f@intel.com> From: Tudor Cornea Date: Wed, 29 Sep 2021 13:03:56 +0300 Message-ID: To: Ferruh Yigit Cc: linville@tuxdriver.com, Thomas Monjalon , Mihai Pogonaru , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v2] net/af_packet: fix ignoring full ring on tx X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ferruh, What you described above looks like a ring buffer with single producer and > single consumer, and producer overwrites the not consumed items. Indeed. This is also my understanding of the bug. I am going to try to isolate the issue, and should probably be able to come up with a script in a few days. Our of curiosity, are you using an modified af_packet implementation in > kernel > for above described usage? We are currently using an Ubuntu-based distro with a 4.15 Linux kernel. We don't have any kernel patches for the af_packet implementation to my knowledge (probably excepting patches that are back-ported by Ubuntu maintainers from newer releases). On Mon, 20 Sept 2021 at 20:44, Ferruh Yigit wrote: > On 9/13/2021 2:45 PM, Tudor Cornea wrote: > > The poll call can return POLLERR which is ignored, or it can return > > POLLOUT, even if there are no free frames in the mmap-ed area. > > > > We can account for both of these cases by re-checking if the next > > frame is empty before writing into it. > > > > Signed-off-by: Mihai Pogonaru > > Signed-off-by: Tudor Cornea > > --- > > drivers/net/af_packet/rte_eth_af_packet.c | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/drivers/net/af_packet/rte_eth_af_packet.c > b/drivers/net/af_packet/rte_eth_af_packet.c > > index b73b211..087c196 100644 > > --- a/drivers/net/af_packet/rte_eth_af_packet.c > > +++ b/drivers/net/af_packet/rte_eth_af_packet.c > > @@ -216,6 +216,25 @@ eth_af_packet_tx(void *queue, struct rte_mbuf > **bufs, uint16_t nb_pkts) > > (poll(&pfd, 1, -1) < 0)) > > break; > > > > + /* > > + * Poll can return POLLERR if the interface is down > > + * > > + * It will almost always return POLLOUT, even if there > > + * are no extra buffers available > > + * > > + * This happens, because packet_poll() calls > datagram_poll() > > + * which checks the space left in the socket buffer and, > > + * in the case of packet_mmap, the default socket buffer > length > > + * doesn't match the requested size for the tx_ring. > > + * As such, there is almost always space left in socket > buffer, > > + * which doesn't seem to be correlated to the requested > size > > + * for the tx_ring in packet_mmap. > > + * > > + * This results in poll() returning POLLOUT. > > + */ > > + if (ppd->tp_status != TP_STATUS_AVAILABLE) > > + break; > > + > > If 'POLLOUT' doesn't indicate that there is space in the buffer, what is > the > point of the 'poll()' at all? > > What can we test/reproduce the mentioned behavior? Or is there a way to > fix the > behavior of poll() or use an alternative of it? > > > OK to break on the 'POLLERR', I guess it can be detected in the > 'pfd.revent'. > > > > /* copy the tx frame data */ > > pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN - > > sizeof(struct sockaddr_ll); > > > >