From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA7C5C31E46 for ; Wed, 12 Jun 2019 14:10:31 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 67A2620866 for ; Wed, 12 Jun 2019 14:10:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67A2620866 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B87D61C610; Wed, 12 Jun 2019 16:10:30 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 662C31C57F for ; Wed, 12 Jun 2019 16:10:29 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2019 07:10:28 -0700 X-ExtLoop1: 1 Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.26]) ([10.237.221.26]) by orsmga006.jf.intel.com with ESMTP; 12 Jun 2019 07:10:26 -0700 To: "Ferriter, Cian" , "Richardson, Bruce" , "Mcnamara, John" , "Kovacevic, Marko" Cc: "dev@dpdk.org" References: <20190605115620.32047-1-cian.ferriter@intel.com> <579B86492DFB364BBA627A48FB30C90E75D518F7@IRSMSX102.ger.corp.intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQkI71rKFiEE 0jZTh0IuwoTjmYHH+TPrQ98TYR8FAlznMMQFCwkIBwMFFQoJCAsFFgIDAQAACgkQ+TPrQ98T YR/B9Q//a57esjq996nfZVm7AsUl7zbvhN+Ojity25ib2gcSVVsAN2j6lcQS4hf6/OVvRj3q CgebJ4o2gXR6X12UzWBJL7NE8Xpc70MvUIe0r11ykurQ9n9jUaWMjxdSqBPF93hU+Z/MZe5M 1rW5O2VJLuTJzkDw3EYUCbHOwPjeaS8Qqj3RI0LYbGthbHBIp9CsjkgsJSjTT5GQ8AQWkE7I z+hvPx6f1rllfjxFyi4DI3jLhAI+j1Nm+l+ESyoX59HrLTHAvq4RPkLpTnGBj9gOnJ+5sVEr GE0fcffsNcuMSkpqSEoJCPAHmChoLgezskhhsy0BiU3xlSIj1Dx2XMDerUXFOK3ftlbYNRte HQy4EKubfZRB8H5Rvcpksom3fRBDcJT8zw+PTH14htRApU9f8I/RamQ7Ujks7KuaB7JX5QaG gMjfPzHGYX9PfF6KIchaFmAWLytIP1t0ht8LpJkjtvUCSQZ2VxpCXwKyUzPDIF3co3tp90o7 X07uiC5ymX0K0+Owqs6zeslLY6DMxNdt8ye+h1TVkSZ5g4dCs4C/aiEF230+luL1CnejOv/K /s1iSbXQzJNM7be3FlRUz4FdwsfKiJJF7xYALSBnSvEB04R7I2P2V9Zpudkq6DRT6HZjBeJ1 pBF2J655cdoenPBIeimjnnh4K7YZBzwOLJf2c6u76fe5Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXOcvZgUJBvIWKAAKCRD5M+tD3xNhHxhBD/9toXMIaPIVFd9w1nKsRDM1GE6gZe4jie8q MJpeHB9O+936fSXA0W2X0het60wJQQ45O8TpTcxpc9nGzcE4MTaLAI3E8TjIXAO0cPqUNLyp g0DXezmTw5BU+SKZ51+jSKOtFmzJCHOJZQaMeCHD+G3CrdUHQVQBb5AeuH3KFv9ltgDcWsc8 YO70o3+tGHwcEnyXLdrI0q05wV7ncnLdkgVo+VUN4092bNMPwYly1TZWcU3Jw5gczOUEfTY7 sgo6E/sGX3B+FzgIs5t4yi1XOweCAQ/mPnb6uFeNENEFyGKyMG1HtjwBqnftbiFO3qitEIUY xWGQH23oKscv7i9lT0gg2D+ktzZhVWwHJVY/2vWSB9aCSWChcH2BT+lWrkwSpoPhy+almM84 Qz2wF72/d4ce4L27pSrS+vOXtXHLGOOGcAn8yr9TV0kM4aR+NbGBRXGKhG6w4lY54uNd9IBa ARIPUhij5JSygxZCBaJKo+X64AHGkk5bXq+f0anwAMNuJXbYC/lz4DEdKmPgQGShOWNs1Y1a N3cI87Hun/RBVwQ0a3Tr1g6OWJ6xK8cYbMcoR8NZ7L9ALMeJeuUDQR39+fEeHg/6sQN0P0mv 0sL+//BAJphCzDk8ztbrFw+JaPtgzZpRSM6JhxnY+YMAsatJRXA0WSpYP5zzl7yu/GZJIgsv VQ== Message-ID: <7ac9657f-e67b-ffc0-1aa3-91693f497aeb@intel.com> Date: Wed, 12 Jun 2019 15:10:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <579B86492DFB364BBA627A48FB30C90E75D518F7@IRSMSX102.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 19.08 v2] net/pcap: enable infinitely rxing a pcap file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On 6/5/2019 1:46 PM, Ferriter, Cian wrote: > Adding in my changelog at the top of this, since I forgot to add it in the original mail: > > v2: > * Rework the method of filling the ring to infinitely rx from > * Avoids potential huge allocation of mbufs > * Removes double allocation of mbufs used during queue setup > * rename count_packets_in_pcaps to count_packets_in_pcap > * initialize pcap_pkt_count in count_packets_in_pcap > * use RTE_PMD_REGISTER_PARAM_STRING <0|1> rather than > * replace calls to rte_panic with proper error returning > * count rx and tx stat bytes in pcap_rx_infinite and tx_drop > * make internals->infinite_rx = infinite_rx assignment unconditional > * add cleanup for infinite_rx in eth_dev_close and pmd_pcap_remove > * add cleanup when multi seg mbufs are found > * add some clarifications to the documentation update > >> -----Original Message----- >> From: Ferriter, Cian >> Sent: 05 June 2019 12:56 >> To: Richardson, Bruce ; Yigit, Ferruh >> ; Mcnamara, John ; >> Kovacevic, Marko >> Cc: dev@dpdk.org; Ferriter, Cian >> Subject: [PATCH 19.08 v2] net/pcap: enable infinitely rxing a pcap file >> >> It can be useful to use pcap files for some rudimental performance testing. >> This patch enables this functionality in the pcap driver. >> >> At a high level, this works by creaing a ring of sufficient size to store the >> packets in the pcap file passed to the application. When the rx function for >> this mode is called, packets are dequeued from the ring for use by the >> application and also enqueued back on to the ring to be "received" again. >> >> A tx_drop mode is also added since transmitting to a tx_pcap file isn't >> desirable at a high traffic rate. >> >> Jumbo frames are not supported in this mode. When filling the ring at rx >> queue setup time, the presence of multi segment mbufs is checked for. >> The PMD will exit on detection of these multi segment mbufs. >> >> Signed-off-by: Cian Ferriter >> --- >> doc/guides/nics/pcap_ring.rst | 19 +++ >> drivers/net/pcap/rte_eth_pcap.c | 268 >> ++++++++++++++++++++++++++++++-- >> 2 files changed, 277 insertions(+), 10 deletions(-) >> >> diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst >> index c1ef9196b..b272e6fe3 100644 >> --- a/doc/guides/nics/pcap_ring.rst >> +++ b/doc/guides/nics/pcap_ring.rst >> @@ -106,6 +106,25 @@ Runtime Config Options >> >> --vdev 'net_pcap0,iface=eth0,phy_mac=1' >> >> +- Use the RX PCAP file to infinitely receive packets >> + >> + In case ``rx_pcap=`` configuration is set, user may want to use the >> + selected PCAP file for rudimental performance testing. This can be done >> with a ``devarg`` ``infinite_rx``, for example:: >> + >> + --vdev 'net_pcap0,rx_pcap=file_rx.pcap,infinite_rx=1,tx_drop=1' Can be good to highlight that this flag is not per queue, but should be provided once (explictly once since code checks it) per Rx. >> + >> + When this mode is used, it is recommended to use the ``tx_drop`` >> ``devarg``. >> + >> + This option is device wide, so all queues on a device will either have this >> enabled or disabled. >> + >> +- Drop all packets on transmit >> + >> + The user may want to drop all packets on tx for a device. This can be done >> with the ``tx_drop`` ``devarg``, for example:: >> + >> + --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_drop=1' >> + >> + One tx drop queue is created for each rxq on that device. Can we drop the ``tx_drop`` completely? What happens when no 'tx_pcap' or 'tx_iface' provided at all, to imply the tx_drop? <...> >> @@ -1105,7 +1290,8 @@ static int >> eth_from_pcaps(struct rte_vdev_device *vdev, >> struct pmd_devargs *rx_queues, const unsigned int >> nb_rx_queues, >> struct pmd_devargs *tx_queues, const unsigned int >> nb_tx_queues, >> - int single_iface, unsigned int using_dumpers) >> + int single_iface, unsigned int using_dumpers, >> + unsigned int infinite_rx, unsigned int tx_drop) The argument list is keep increasing. What happens is 'pmd_pcap_probe()' processes the user input (devargs) and passes the processed output to this function to create ethdev. What do you think gathering all processed output to a struct and pass it the this function, in a patch before this patch? Like: struct pmd_devargs_all { struct pmd_devargs pcaps; struct pmd_devargs dumpers; int single_iface; unsigned intis_tx_pcap; }; And add 'unsigned int infinite_rx;' into that struct in this patch. <...> >> @@ -1148,6 +1342,7 @@ pmd_pcap_probe(struct rte_vdev_device *dev) { >> const char *name; >> unsigned int is_rx_pcap = 0, is_tx_pcap = 0; >> + unsigned int infinite_rx = 0, infinite_rx_arg_cnt = 0, tx_drop = 0; Is initial value required for 'infinite_rx_arg_cnt '? >> struct rte_kvargs *kvlist; >> struct pmd_devargs pcaps = {0}; >> struct pmd_devargs dumpers = {0}; >> @@ -1216,7 +1411,25 @@ pmd_pcap_probe(struct rte_vdev_device *dev) >> is_rx_pcap = rte_kvargs_count(kvlist, ETH_PCAP_RX_PCAP_ARG) ? 1 >> : 0; >> pcaps.num_of_queue = 0; >> >> + infinite_rx_arg_cnt = rte_kvargs_count(kvlist, >> + ETH_PCAP_INFINITE_RX_ARG); Can move this under 'is_rx_pcap', since this value only make sense when Rx is pcap. >> + >> if (is_rx_pcap) { >> + /* >> + * We check whether we want to infinitely rx the pcap file. >> + */ >> + if (infinite_rx_arg_cnt == 1) { >> + ret = rte_kvargs_process(kvlist, >> + ETH_PCAP_INFINITE_RX_ARG, >> + &get_infinite_rx_arg, &infinite_rx); >> + if (ret < 0) >> + goto free_kvlist; >> + } else if (infinite_rx_arg_cnt >= 1) { I guess it should be ">" instead of ">=" <...> >> @@ -1285,8 +1512,12 @@ pmd_pcap_probe(struct rte_vdev_device *dev) >> goto free_kvlist; >> } >> >> + PMD_LOG(INFO, "Configure pmd_pcap: infinite_rx is %s", >> + infinite_rx ? "enabled" : "disabled"); What do you think printing the message when feature is requested? Instead of printing each time that it is disabled, which is default behaviour. <...> >> @@ -1318,6 +1550,20 @@ pmd_pcap_remove(struct rte_vdev_device *dev) >> eth_dev->data->mac_addrs = NULL; >> } >> >> + /* Device wide flag, but cleanup must be performed per queue. */ >> + if (internals->infinite_rx) { >> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) { >> + struct pcap_rx_queue *pcap_q = &internals- >>> rx_queue[i]; >> + struct rte_mbuf *pcap_buf; >> + >> + while (!rte_ring_dequeue(pcap_q->pkts, >> + (void **)&pcap_buf)) >> + rte_pktmbuf_free(pcap_buf); >> + >> + rte_ring_free(pcap_q->pkts); >> + } >> + } Can it possible to call 'eth_dev_close()' which seems dublicating the above code?