DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org
Cc: Ido Goshen <ido@cgstowernetworks.com>
Subject: Re: [PATCH v2] pcap: support MTU set
Date: Wed, 5 Jul 2023 12:37:41 +0100	[thread overview]
Message-ID: <a8f51626-5930-21f1-80fc-50451cf58c0d@amd.com> (raw)
In-Reply-To: <20230704210237.72933-1-stephen@networkplumber.org>

On 7/4/2023 10:02 PM, Stephen Hemminger wrote:
> Support rte_eth_dev_set_mtu for pcap driver when the
> pcap device is convigured to point to a network interface.
> 
> This is rebased an consolidated from earlier version.
> Added support for FreeBSD.
> 

As far as I understand motivation is to make pcap PMD behave close the
physical NIC and able to test the application MTU feature.
If so, Ido's v4 was simpler, which doesn't distinguish if pcap backed by
physical interface or .pcap file.
What was wrong with that approach?

> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> v2 - fix FreeBSD part
> 
>  drivers/net/pcap/pcap_ethdev.c        | 49 ++++++++++++++++++++++++++-
>  drivers/net/pcap/pcap_osdep.h         |  1 +
>  drivers/net/pcap/pcap_osdep_freebsd.c | 23 +++++++++++++
>  drivers/net/pcap/pcap_osdep_linux.c   | 21 ++++++++++++
>  drivers/net/pcap/pcap_osdep_windows.c |  7 ++++
>  5 files changed, 100 insertions(+), 1 deletion(-)
> 

Better to update driver documentation and release notes too.

> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index bfec0850456f..672f42d30d8e 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <stdlib.h>
> +#include <stdbool.h>
>  #include <time.h>
>  
>  #include <pcap.h>
> @@ -495,8 +496,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>  		 */
>  		ret = pcap_sendpacket(pcap,
>  			rte_pktmbuf_read(mbuf, 0, len, temp_data), len);
> -		if (unlikely(ret != 0))
> +		if (unlikely(ret != 0)) {
> +			/* Oversize packet dropped due to MTU */
> +			if (errno == EMSGSIZE)
> +				continue;

This will leak mbuf, since loop continues application will assume driver
sent the packet and freed mbuf. Ido's version does it right.

>  			break;
> +		}
> +
>  		num_tx++;
>  		tx_bytes += len;
>  		rte_pktmbuf_free(mbuf);
> @@ -808,6 +814,46 @@ eth_stats_reset(struct rte_eth_dev *dev)
>  	return 0;
>  }
>  
> +static int
> +eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> +{
> +	struct pmd_internals *internals = dev->data->dev_private;
> +	unsigned int i;
> +	bool is_supported = false;
> +	int ret;
> +
> +	for (i = 0; i < dev->data->nb_rx_queues; i++) {
> +		struct pcap_rx_queue *queue = &internals->rx_queue[i];
> +
> +		if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
> +		    (strcmp(queue->type, ETH_PCAP_RX_IFACE_ARG) == 0) ||
> +		    (strcmp(queue->type, ETH_PCAP_RX_IFACE_IN_ARG) == 0)) {
> +			ret = osdep_iface_mtu_set(queue->name, mtu);
> +			if (ret < 0)
> +				return ret;
> +			is_supported = true;
> +		}

If there are multiple devices (each pcap queue represents a device), and
one in the middle one fails to set MTU, there will be mixed MTU values
in devices.

> +	}
> +
> +	for (i = 0; i < dev->data->nb_tx_queues; i++) {
> +		struct pcap_tx_queue *queue = &internals->tx_queue[i];
> +
> +		if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||

Rx devices and Tx devices can be same device, causing duplicated MTU set
for same device, but it is hard to detect if they are same devices.
At least it is easier to detect when queue type is 'ETH_PCAP_IFACE_ARG',
what about set MTU once for this queue type?


  reply	other threads:[~2023-07-05 11:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 17:43 [PATCH] net/pcap: " ido g
2022-03-17 18:20 ` Stephen Hemminger
2022-03-17 19:11   ` Ido Goshen
2022-03-22 13:02     ` Ido Goshen
2022-04-26 17:03       ` Ferruh Yigit
2022-04-27 18:21         ` Ido Goshen
2022-04-27 19:14           ` Stephen Hemminger
2022-05-23  7:48             ` Ido Goshen
2022-05-30 10:36 ` [PATCH v3] pcap: " Ido Goshen
2022-05-30 18:05   ` Ferruh Yigit
2022-05-31 13:12     ` Ido Goshen
2022-06-06  9:40     ` Ido Goshen
2022-06-06 16:21 ` [PATCH v4] " Ido Goshen
2022-06-06 17:10   ` Stephen Hemminger
2022-06-06 19:07     ` Ido Goshen
2022-06-07  6:27 ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
2022-06-08 16:04   ` [PATCH v6] " Ido Goshen
2022-06-08 16:23     ` Stephen Hemminger
2022-06-19  9:30 ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-19  9:30   ` [PATCH v7 1/3] " Ido Goshen
2022-06-19  9:30   ` [PATCH v7 2/3] pcap: support MTU set for linux interfaces TX enhancment Ido Goshen
2022-06-20 22:52     ` Stephen Hemminger
2022-06-21  9:07       ` Ido Goshen
2022-06-19  9:30   ` [PATCH v7 3/3] pcap: support MTU set for linux interfaces count ierrors Ido Goshen
2022-06-20  8:39 ` [PATCH v8 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20  8:39   ` [PATCH v8 1/3] " Ido Goshen
2022-06-20  8:39   ` [PATCH v8 2/3] pcap: support MTU set for linux interfaces TX enhancment Ido Goshen
2022-06-20  8:39   ` [PATCH v8 3/3] pcap: support MTU set for linux interfaces count ierrors Ido Goshen
2023-07-04 17:43 ` [PATCH] pcap: support MTU set Stephen Hemminger
2023-07-04 21:02 ` [PATCH v2] " Stephen Hemminger
2023-07-05 11:37   ` Ferruh Yigit [this message]
2023-07-05 15:18     ` Stephen Hemminger
2023-07-06 10:45       ` Ido Goshen
2023-07-10 16:45 ` [PATCH] net/pcap: " Stephen Hemminger
2023-07-10 17:46   ` Ferruh Yigit
2023-07-11  9:41     ` Ido Goshen
2022-05-23 14:27 [PATCH v2] pcap: " Ido Goshen
2022-05-23 14:52 ` Ido Goshen

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=a8f51626-5930-21f1-80fc-50451cf58c0d@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=dev@dpdk.org \
    --cc=ido@cgstowernetworks.com \
    --cc=stephen@networkplumber.org \
    /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).