[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