[dpdk-dev] [dpdk-dev,v1] net/tap: add tun support
Varghese, Vipin
vipin.varghese at intel.com
Mon Feb 26 12:01:14 CET 2018
Hi Pascal,
Thanks for the comments, Please find my updates inline
> -----Original Message-----
> From: Pascal Mazon [mailto:pascal.mazon at 6wind.com]
> Sent: Thursday, February 22, 2018 12:22 PM
> To: Varghese, Vipin <vipin.varghese at intel.com>; dev at dpdk.org; Mcnamara,
> John <john.mcnamara at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>
> Cc: Kovacevic, Marko <marko.kovacevic at intel.com>
> Subject: Re: [dpdk-dev,v1] net/tap: add tun support
>
> Personally, I'm mostly ok with this.
> I added a couple of comments inline.
>
<snipped>
> > +The TUN PMD allows user to create a TUN device on host. The PMD
> > +allows user to transmit and recieve packets via DPDK API calls with L3
> header and payload.
> s/recieve/receive/
Thanks, making the changes for the next version
> > +The devices in host can be accessed via ``ifconfig`` or ``ip``
> > +command. TUN interfaces are passed to DPDK ``rte_eal_init`` arguments
> > +as ``--vdev=net_tunX``, where X stands for unique id, example::
<snipped>
> >
> > static int tap_unit;
> > +static int tun_unit;
> > +
> > +static int tap_type;
> I'm not a huge fan of considering "tap_type = 1 means it's a TAP device".
> Wouldn't it be clearer to have a tuntap_type variable and an enum
> TUNTAP_TYPE with the two types; then checking for tuntap_type ==
> TUN_TYPE or tuntap == TAP_TYPE?
> It's not a deal breaker though, just a consideration.
Thanks, my first idea was use the same. Later argued myself in using 'tap_type' since the check for assigning MAC address goes well. Hence I hope not making the change 'tuntap_type' is ok?
> > +static char tuntap_name[8];
> >
> > static volatile uint32_t tap_trigger; /* Rx trigger */
> >
<snipped>
> > RTE_PMD_REGISTER_PARAM_STRING(net_tap,
> > ETH_TAP_IFACE_ARG "=<string> "
> The rest looks fine.
>
> Regards,
> Pascal
More information about the dev
mailing list