DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
To: Ido Goshen <ido@cgstowernetworks.com>, <ferruh.yigit@xilinx.com>,
	<stephen@networkplumber.org>
Cc: <dev@dpdk.org>, Tianli Lai <laitianli@tom.com>
Subject: Re: [PATCH v3] pcap: support MTU set
Date: Mon, 30 May 2022 19:05:44 +0100	[thread overview]
Message-ID: <e1fd4d8f-0d5a-ae00-f0fe-b7aa8cf5e6e6@xilinx.com> (raw)
In-Reply-To: <20220530103647.35626-1-ido@cgstowernetworks.com>

On 5/30/2022 11:36 AM, Ido Goshen wrote:
> Support rte_eth_dev_set_mtu by pcap vdevs
> Enforce mtu on rx/tx
> 

Still not sure about enforcing MTU on pcap, but please find comments on 
mechanical issues

> Bugzilla ID: 961
> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
> 
> ---
> v3:
> Preserve pcap behavior to support max size packets by default
> alternative to v2 in order to limit the code change to pcap only and
> avoid abi change.
> Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
> 
> v2:
> Preserve pcap behavior to support max size packets by default.
> ---
>   drivers/net/pcap/pcap_ethdev.c | 44 +++++++++++++++++++++++++++++++---
>   1 file changed, 41 insertions(+), 3 deletions(-)
> 

Is documentation needs to be updated as well?

And what do you think to update release notes for this update?

> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index ec29fd6bc5..2e7fff9579 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -93,6 +93,7 @@ struct pmd_internals {
>   	int single_iface;
>   	int phy_mac;
>   	unsigned int infinite_rx;
> +	int is_mtu_set;
>   };
>   
>   struct pmd_process_private {
> @@ -278,11 +279,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	const u_char *packet;
>   	struct rte_mbuf *mbuf;
>   	struct pcap_rx_queue *pcap_q = queue;
> +	struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
> +	struct pmd_internals *internals = dev->data->dev_private;

'rte_eth_devices[]' needs to be used for 'process_private' but lets not 
tie it to access 'dev_private'.

You can add "struct pmd_internals *" to the "struct pcap_rx_queue" & 
"struct pcap_tx_queue" structs for the access. Please check null PMD for 
sample.

>   	uint16_t num_rx = 0;
>   	uint32_t rx_bytes = 0;
>   	pcap_t *pcap;
>   
> -	pp = rte_eth_devices[pcap_q->port_id].process_private;
> +	pp = dev->process_private;
>   	pcap = pp->rx_pcap[pcap_q->queue_id];
>   
>   	if (unlikely(pcap == NULL || nb_pkts == 0))
> @@ -303,6 +306,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   			break;
>   		}
>   
> +		if (unlikely(header.caplen > dev->data->mtu) &&
> +				internals->is_mtu_set) {
> +			pcap_q->rx_stat.err_pkts++;
> +			rte_pktmbuf_free(mbuf);
> +			break;
> +		}
> +
>   		if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
>   			/* pcap packet will fit in the mbuf, can copy it */
>   			rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> @@ -378,6 +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	struct rte_mbuf *mbuf;
>   	struct pmd_process_private *pp;
>   	struct pcap_tx_queue *dumper_q = queue;
> +	struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
> +	struct pmd_internals *internals = dev->data->dev_private;
>   	uint16_t num_tx = 0;
>   	uint32_t tx_bytes = 0;
>   	struct pcap_pkthdr header;
> @@ -385,7 +397,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
>   	size_t len, caplen;
>   
> -	pp = rte_eth_devices[dumper_q->port_id].process_private;
> +	pp = dev->process_private;
>   	dumper = pp->tx_dumper[dumper_q->queue_id];
>   
>   	if (dumper == NULL || nb_pkts == 0)
> @@ -396,6 +408,13 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	for (i = 0; i < nb_pkts; i++) {
>   		mbuf = bufs[i];
>   		len = caplen = rte_pktmbuf_pkt_len(mbuf);
> +
> +		if (unlikely(len > dev->data->mtu) &&
> +				internals->is_mtu_set) {

It is possible to save only some part of the packet to the pcap file, 
please check snaplen patch [1], how MTU config should work with this 
feature?

[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220313112638.3945-1-laitianli@tom.com/

> +			rte_pktmbuf_free(mbuf);
> +			continue;

Normally a PMD should not silently free a packet itself, it should 
return error and application will decide to free the packet or not.

> +		}
> +
>   		if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
>   				len > sizeof(temp_data))) {
>   			caplen = sizeof(temp_data);
> @@ -464,13 +483,15 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	struct rte_mbuf *mbuf;
>   	struct pmd_process_private *pp;
>   	struct pcap_tx_queue *tx_queue = queue;
> +	struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
> +	struct pmd_internals *internals = dev->data->dev_private;
>   	uint16_t num_tx = 0;
>   	uint32_t tx_bytes = 0;
>   	pcap_t *pcap;
>   	unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
>   	size_t len;
>   
> -	pp = rte_eth_devices[tx_queue->port_id].process_private;
> +	pp = dev->process_private;
>   	pcap = pp->tx_pcap[tx_queue->queue_id];
>   
>   	if (unlikely(nb_pkts == 0 || pcap == NULL))
> @@ -479,6 +500,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>   	for (i = 0; i < nb_pkts; i++) {
>   		mbuf = bufs[i];
>   		len = rte_pktmbuf_pkt_len(mbuf);
> +
> +		if (unlikely(len > dev->data->mtu) &&
> +				internals->is_mtu_set) {
> +			rte_pktmbuf_free(mbuf);
> +			continue;

ditto

> +		}
> +
>   		if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
>   				len > sizeof(temp_data))) {
>   			PMD_LOG(ERR,
> @@ -807,6 +835,14 @@ eth_stats_reset(struct rte_eth_dev *dev)
>   	return 0;
>   }
>   
> +static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

Please follow coding convention to have return type in a separate line:
   static int
   eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
   {

> +{
> +	PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);

Can you please move the log after variable declerations. And can be good 
to capitilise MTU in the log.

> +	struct pmd_internals *internals = dev->data->dev_private;
> +	internals->is_mtu_set = 1;
> +	return 0;
> +}
> +
>   static inline void
>   infinite_rx_ring_free(struct rte_ring *pkts)
>   {
> @@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
>   	.link_update = eth_link_update,
>   	.stats_get = eth_stats_get,
>   	.stats_reset = eth_stats_reset,
> +	.mtu_set = eth_mtu_set,
>   };
>   
>   static int
> @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
>   		.addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
>   	};
>   	(*internals)->phy_mac = 0;
> +	(*internals)->is_mtu_set = 0;
>   	data = (*eth_dev)->data;
>   	data->nb_rx_queues = (uint16_t)nb_rx_queues;
>   	data->nb_tx_queues = (uint16_t)nb_tx_queues;


  reply	other threads:[~2022-05-30 18:05 UTC|newest]

Thread overview: 36+ 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 [this message]
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
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

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=e1fd4d8f-0d5a-ae00-f0fe-b7aa8cf5e6e6@xilinx.com \
    --to=ferruh.yigit@xilinx.com \
    --cc=dev@dpdk.org \
    --cc=ido@cgstowernetworks.com \
    --cc=laitianli@tom.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).