From: "Wiles, Keith" <keith.wiles@intel.com>
To: Pascal Mazon <pascal.mazon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/tap: add support for fixed mac addresses
Date: Tue, 11 Apr 2017 15:42:32 +0000 [thread overview]
Message-ID: <AA7E2728-D9AA-466F-9E43-33FCF1D34063@intel.com> (raw)
In-Reply-To: <5c2f65e8087fffc62c03b0c36b01a3058f203254.1491923112.git.pascal.mazon@6wind.com>
> On Apr 11, 2017, at 10:09 AM, Pascal Mazon <pascal.mazon@6wind.com> wrote:
>
> Support for a fixed MAC address for testing with the last octet
> incrementing by one for each interface defined with the new 'mac=fixed'
> string on the --vdev option. The default option is still to randomize
> the MAC address for each tap interface.
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> Signed-off-by: Pascal Mazon <pascal.mazon@6wind.com>
> ---
>
> Hi Keith, I've made the changes I suggested.
>
> It does as expected use a mac incremented by 1 for each new tap device,
> without a global variable for fixed_mac_type.
>
> With the more clean "\0dtap" initialization for mac[], I do think it
> looks better, don't you?
> I agree my version with \x did little improvement to yours, and would
> be a question of style.
> What do you say of this patch?
>
> doc/guides/nics/tap.rst | 13 ++++++++++++-
> drivers/net/tap/rte_eth_tap.c | 39 ++++++++++++++++++++++++++++++++++++---
> 2 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> index 5c5ba5357bba..f3ee95d2897b 100644
> --- a/doc/guides/nics/tap.rst
> +++ b/doc/guides/nics/tap.rst
> @@ -46,7 +46,7 @@ These TAP interfaces can be used with Wireshark or tcpdump or Pktgen-DPDK
> along with being able to be used as a network connection to the DPDK
> application. The method enable one or more interfaces is to use the
> ``--vdev=net_tap0`` option on the DPDK application command line. Each
> -``--vdev=net_tap1`` option give will create an interface named dtap0, dtap1,
> +``--vdev=net_tap1`` option given will create an interface named dtap0, dtap1,
> and so on.
>
> The interface name can be changed by adding the ``iface=foo0``, for example::
> @@ -58,6 +58,17 @@ needed, but the interface does not enforce that speed, for example::
>
> --vdev=net_tap0,iface=foo0,speed=25000
>
> +Normally the PMD will generate a random MAC address, but when testing or with
> +a static configuration the developer may need a fixed MAC address style.
> +Using the option ``mac=fixed`` you can create a fixed known MAC address::
> +
> + --vdev=net_tap0,mac=fixed
> +
> +The MAC address will have a fixed value with the last octet incrementing by one
> +for each interface string containing ``mac=fixed``. The MAC address is formatted
> +as 00:'d':'t':'a':'p':[00-FF]. Convert the characters to hex and you get the
> +actual MAC address: ``00:64:74:61:70:[00-FF]``.
> +
> It is possible to specify a remote netdevice to capture packets from by adding
> ``remote=foo1``, for example::
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index cd82a7e09c75..2092f5d4184b 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -1,7 +1,7 @@
> /*-
> * BSD LICENSE
> *
> - * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + * Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -71,6 +71,8 @@
> #define ETH_TAP_IFACE_ARG "iface"
> #define ETH_TAP_SPEED_ARG "speed"
> #define ETH_TAP_REMOTE_ARG "remote"
> +#define ETH_TAP_MAC_ARG "mac"
> +#define ETH_TAP_MAC_FIXED "fixed"
>
> #define FLOWER_KERNEL_VERSION KERNEL_VERSION(4, 2, 0)
> #define FLOWER_VLAN_KERNEL_VERSION KERNEL_VERSION(4, 9, 0)
> @@ -81,6 +83,7 @@ static const char *valid_arguments[] = {
> ETH_TAP_IFACE_ARG,
> ETH_TAP_SPEED_ARG,
> ETH_TAP_REMOTE_ARG,
> + ETH_TAP_MAC_ARG,
> NULL
> };
>
> @@ -1131,7 +1134,8 @@ tap_kernel_support(struct pmd_internals *pmd)
> }
>
> static int
> -eth_dev_tap_create(const char *name, char *tap_name, char *remote_iface)
> +eth_dev_tap_create(const char *name, char *tap_name, char *remote_iface,
> + int fixed_mac_type)
> {
> int numa_node = rte_socket_id();
> struct rte_eth_dev *dev = NULL;
> @@ -1229,6 +1233,13 @@ eth_dev_tap_create(const char *name, char *tap_name, char *remote_iface)
> }
> rte_memcpy(&pmd->eth_addr, ifr.ifr_hwaddr.sa_data,
> ETHER_ADDR_LEN);
> + } else if (fixed_mac_type) {
> + /* fixed mac = 00:64:74:61:70:<iface_idx> */
> + static int iface_idx;
> + char mac[ETHER_ADDR_LEN] = "\0dtap";
> +
> + mac[ETHER_ADDR_LEN - 1] = iface_idx++;
> + rte_memcpy(&pmd->eth_addr, mac, ETHER_ADDR_LEN);
> } else {
> eth_random_addr((uint8_t *)&pmd->eth_addr);
> }
This does not show up as a change in the patch, I thought it should.
> @@ -1285,6 +1296,17 @@ set_remote_iface(const char *key __rte_unused,
> return 0;
> }
>
> +static int
> +set_mac_type(const char *key __rte_unused,
> + const char *value,
> + void *extra_args)
> +{
> + if (value &&
> + !strncasecmp(ETH_TAP_MAC_FIXED, value, strlen(ETH_TAP_MAC_FIXED)))
> + *(int *)extra_args = 1;
> + return 0;
> +}
> +
> /* Open a TAP interface device.
> */
> static int
> @@ -1295,6 +1317,7 @@ rte_pmd_tap_probe(const char *name, const char *params)
> int speed;
> char tap_name[RTE_ETH_NAME_MAX_LEN];
> char remote_iface[RTE_ETH_NAME_MAX_LEN];
> + int fixed_mac_type = 0;
>
> speed = ETH_SPEED_NUM_10G;
> snprintf(tap_name, sizeof(tap_name), "%s%d",
> @@ -1332,6 +1355,15 @@ rte_pmd_tap_probe(const char *name, const char *params)
> if (ret == -1)
> goto leave;
> }
> +
> + if (rte_kvargs_count(kvlist, ETH_TAP_MAC_ARG) == 1) {
> + ret = rte_kvargs_process(kvlist,
> + ETH_TAP_MAC_ARG,
> + &set_mac_type,
> + &fixed_mac_type);
> + if (ret == -1)
> + goto leave;
> + }
> }
> }
> pmd_link.link_speed = speed;
> @@ -1339,7 +1371,7 @@ rte_pmd_tap_probe(const char *name, const char *params)
> RTE_LOG(NOTICE, PMD, "Initializing pmd_tap for %s as %s\n",
> name, tap_name);
>
> - ret = eth_dev_tap_create(name, tap_name, remote_iface);
> + ret = eth_dev_tap_create(name, tap_name, remote_iface, fixed_mac_type);
>
> leave:
> if (ret == -1) {
> @@ -1397,4 +1429,5 @@ RTE_PMD_REGISTER_ALIAS(net_tap, eth_tap);
> RTE_PMD_REGISTER_PARAM_STRING(net_tap,
> ETH_TAP_IFACE_ARG "=<string> "
> ETH_TAP_SPEED_ARG "=<int> "
> + ETH_TAP_MAC_ARG "=" ETH_TAP_MAC_FIXED " "
> ETH_TAP_REMOTE_ARG "=<string>");
> --
> 2.12.0.306.g4a9b9b3
>
Regards,
Keith
next prev parent reply other threads:[~2017-04-11 15:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 18:18 Keith Wiles
2017-04-11 7:18 ` Pascal Mazon
2017-04-11 8:31 ` Ferruh Yigit
2017-04-11 13:23 ` Wiles, Keith
2017-04-11 13:25 ` Wiles, Keith
2017-04-11 13:39 ` Ferruh Yigit
2017-04-11 13:41 ` Wiles, Keith
2017-04-11 13:54 ` Pascal Mazon
2017-04-11 14:17 ` Wiles, Keith
2017-04-11 15:09 ` Pascal Mazon
2017-04-11 15:38 ` Wiles, Keith
2017-04-11 15:42 ` Wiles, Keith [this message]
2017-04-11 15:49 ` Ferruh Yigit
2017-04-11 16:16 ` Wiles, Keith
2017-04-12 7:30 ` [dpdk-dev] [PATCH v2] " Pascal Mazon
2017-04-14 9:45 ` Ferruh Yigit
2017-05-12 12:24 ` Ferruh Yigit
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=AA7E2728-D9AA-466F-9E43-33FCF1D34063@intel.com \
--to=keith.wiles@intel.com \
--cc=dev@dpdk.org \
--cc=pascal.mazon@6wind.com \
/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).