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;
next prev parent 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).