DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
	Igor Russkikh <igor.russkikh@aquantia.com>,
	Pavel Belous <pavel.belous@aquantia.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	Marcin Wojtas <mw@semihalf.com>,
	Michal Krawczyk <mk@semihalf.com>,
	Guy Tzalik <gtzalik@amazon.com>,
	Evgeny Schemeilin <evgenys@amazon.com>,
	Igor Chauskin <igorch@amazon.com>,
	John Daley <johndale@cisco.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Wang, Xiao W" <xiao.w.wang@intel.com>,
	Ziyang Xuan <xuanziyang2@huawei.com>,
	Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
	Guoyang Zhou <zhouguoyang@huawei.com>,
	"Wei Hu (Xavier)" <xavier.huwei@huawei.com>,
	"Min Hu (Connor)" <humin29@huawei.com>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	Rasesh Mody <rmody@marvell.com>,
	Shahed Shaikh <shshaikh@marvell.com>,
	"Singh, Jasvinder" <jasvinder.singh@intel.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	"Wang, Zhihong" <zhihong.wang@intel.com>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	Yong Wang <yongwang@vmware.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
Date: Wed, 22 Apr 2020 13:02:42 +0200	[thread overview]
Message-ID: <26026576.gRfpFWEtPU@thomas> (raw)
In-Reply-To: <20200422105519.GB1402@bricha3-MOBL.ger.corp.intel.com>

22/04/2020 12:55, Bruce Richardson:
> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> > W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > > 21/04/2020 22:58, Lukasz Wojciechowski:
> > >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> > >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> > >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> > >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> > >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > >>>>>>>>>>>
> > >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> > >>>>>>>>>>> layer meson.build.
> > >>>>>>>>>>>
> > >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> > >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> > >>>>>>>>>>> CFLAGS="-D..."
> > >>>>>>>>>>>
> > >>>>>>>>>>> Konstantin
> > >>>>>>>>>>>
> > >>>>>>>>>> That seems a reasonable idea to me.
> > >>>>>>>>>>
> > >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > >>>>>>>>>> either:
> > >>>>>>>>>>
> > >>>>>>>>>> * allow each component meson.build file define its own flags after
> > >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> > >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> > >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> > >>>>>>>>>> working on it from having to lookup what the define was, since it's
> > >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > >>>>>>>>>> RTE_DEBUG_SCHED etc]
> > >>>>>>>>>>
> > >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> > >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> > >>>>>>>>>>
> > >>>>>>>>>> /Bruce
> > >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> > >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> > >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> > >>>>>>>>> the RTE_DEBUG_... flags
> > >>>>>>>>>
> > >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> > >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> > >>>>>>>>> component
> > >>>>>>>>>
> > >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> > >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> > >>>>>>>>> object and written then later to rte_build_config.h before compilation
> > >>>>>>>>> stage.  All the other modules will be able to use these flags.
> > >>>>>>>>>
> > >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> > >>>>>>>> others are ok with this before you spend too much effort implementing it.
> > >>>>>>>>
> > >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> > >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > >>>>>>>> name confusion. Those flags can then be checked inside individual
> > >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > >>>>>>>> you could theoretically do:
> > >>>>>>>>
> > >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > >>>>>>>> 	...
> > >>>>>>>> endif
> > >>>>>>>>
> > >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> > >>>>>>>> compatibility with existing defines, again if so desired.
> > >>>>>>> Nak the nak from Cristian.
> > >>>>>>>
> > >>>>>>> We don't need all these flags.
> > >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> > >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> > >>>>>>> the interesting logs.
> > >>>>>>> If you need to disable something which is not a log,
> > >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> > >>> For many libs these flags mean much more than just logging.
> > >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > >>> drivers - extra validation performed.
> > >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > >>> rte_mbuf_sanity_check() instead of just NOP.
> > >>> Which means performance would be greatly affected.
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > >>> and enforce extra checking, stats collection.
> > >>> etc.
> > >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> > >>> But I suppose in many cases people just interested to enable debug on one
> > >>> (ok might be two/three) particular libraries, not the whole system.
> > >>> Right now there is such ability, we are going to remove it without
> > >>> providing adequate replacement.
> > >>> Approach with rte_log_can_log() seems workable,
> > >>> but right now these patches don't implement it.
> > >>> Konstantin
> > >>>
> > >>>>>>> Please let's stop complicating things for the contributors and the users.
> > >>>>>>> Note: I am strong on this position.
> > >>>>>>>
> > >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> > >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > >>>>>> that may be some distance from reality right now.
> > >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > >>>>> And next step is to block any patch in those drivers or libs,
> > >>>>> until it is fixed. Dynamic logging should have been complete for long.
> > >>>>>
> > >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> > >>>> the work required here?
> > >>>>
> > >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> > >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> > >>>>>> debug info to binary without affecting code generation.
> > >>>>> OK, we want to keep this flag for gdb symbols only?
> > >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> > >>>>>
> > >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> > >>>> something instead.
> > >>>>
> > >>>> /Bruce
> > >> OK, lets's summarize current opinions and requirements to make a
> > >> proposal for version2 of these patches, that I can implement if all agree:
> > >>
> > >> 1) The global debug flag is required to enable all the sanity checks and
> > >> validations that are normally not used due to performance reasons
> > > Yes
> > >
> > >> 2) The best option would be to have a single flag - not to introduce too
> > >> many build options
> > > Yes
> > >
> > >> 3) This option should be separated from meson "debug" option (used for
> > >> build with symbols) and can be called "rte_debug"
> > > Yes, it looks to be the consensus.
> > >
> > >> 4) The currently existing DEBUG macros should not be replaced with a
> > >> RTE_DEBUG macro. This would allow to still enable them using
> > >> CFLAGS="-D..." to test a single module (library, driver).
> > >>
> > >> 5) Currently existing options' names should be standardized to
> > >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > >> when rte_debug is set. Standardized names would allow easy usage in
> > >> other modules.
> > > I don't understand difference between 4) et 5).
> > 
> > In current version of patches, I replaced all the DEBUG macros with 
> > RTE_DEBUG. It would be much better to keep fine-grained debugs as they 
> > are defined currently in dpdk. This is what I have on mind in 4)
> > 
> > However the currently used debug macros have different naming 
> > conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other 
> > RTE_{name}_DEBUG, some just {name}_DEBUG.
> > So in 5) I follow Bruce's proposal to standardize them to one form 
> > RTE_DEBUG_{name}. However this will change the existing macros and 
> > someone might not like it, so I ask for the opinion about it.
> > 
> My thought is to standardize in the build and then leave it to module
> owners to either change their macros to use those standard ones as time
> goes on.

In order to maintain a good global user experience,
we need to drive such change with a roadmap and deadlines.

> > >> Should they? Or should we leave the current debug macros? Please share
> > >> your opinions as I see both cons and pros of this idea.
> > > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > > In case RTE_DEBUG is enabled, which kind of debug processing
> > > (except logs) do we want to be able to disable?
> > > Is it possible to decide based on a call to rte_log_can_log()?
> > I think it's rather opposite way round. Sometimes we would like to 
> > enable just some debug processing, e.g. when working on single lib or 
> > driver.
> > If we will use rte_debug - every debug  processing would be enabled, we 
> > won't disable anything, but without rte_debug we will still have the 
> > possibility of enabling debugs on a single module.
> > 
> > I believe it is possible to do it with rte_log_can_log, but changing 
> > build time enabled options into runtime enabled options might affect 
> > performance. It might make working on a single library or driver harder.
> > 
> 
> I think the idea is to use both. When RTE_DEBUG is enabled, then the
> rte_log_can_log() calls will be used to control the actual output. Without
> RTE_DEBUG, the whole block is skipped.
> 
> #ifdef RTE_DEBUG
> 	if rte_log_can_log(...) {
> 		/* do debug stuff */
> 	}
> #endif

This is what I had in mind.
The question is about performance impact in the case
we enable RTE_DEBUG at compilation time, and don't enable a
specific debug at runtime: is this check overhead acceptable?
	if rte_log_can_log(...)




  reply	other threads:[~2020-04-22 11:02 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200417215755eucas1p25660167c57c26ef04a82a8bb981e07b5@eucas1p2.samsung.com>
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
     [not found]   ` <CGME20200417215756eucas1p107941824d555cdc91899d529d3c4ee67@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 01/17] config: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215756eucas1p13a995889338901b81bf2a59a5a4f1260@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 02/17] config: remove unused config flags Lukasz Wojciechowski
     [not found]   ` <CGME20200417215759eucas1p1c0fcc3046d87dc9de1d15572ba6b7caa@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one Lukasz Wojciechowski
2020-04-20  9:04       ` Dumitrescu, Cristian
2020-04-20 13:37         ` Ananyev, Konstantin
2020-04-20 14:21           ` Bruce Richardson
2020-04-20 14:43             ` Lukasz Wojciechowski
2020-04-20 17:11               ` Bruce Richardson
2020-04-20 17:21                 ` Thomas Monjalon
2020-04-20 17:30                   ` Bruce Richardson
2020-04-20 17:34                     ` Lukasz Wojciechowski
2023-06-12 16:23                       ` Stephen Hemminger
2020-04-20 17:35                     ` Thomas Monjalon
2020-04-20 18:57                       ` Bruce Richardson
2020-04-21  0:32                         ` Ananyev, Konstantin
2020-04-21 20:58                           ` Lukasz Wojciechowski
2020-04-21 21:38                             ` Thomas Monjalon
2020-04-22 10:41                               ` Lukasz Wojciechowski
2020-04-22 10:55                                 ` Bruce Richardson
2020-04-22 11:02                                   ` Thomas Monjalon [this message]
2020-04-22 11:16                                     ` Bruce Richardson
2020-04-22 11:29                                     ` Ananyev, Konstantin
2020-04-22 12:24                                       ` Thomas Monjalon
2020-07-09 14:09                                         ` Lukasz Wojciechowski
2020-07-14 10:30                                           ` Ananyev, Konstantin
2020-04-22 11:52                                     ` Lukasz Wojciechowski
2020-04-22 12:44                                       ` Bruce Richardson
2020-04-20 17:24                 ` Bruce Richardson
     [not found]   ` <CGME20200417215800eucas1p2f3a71aaf69584fc37c9c4a47c3a2d39d@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 04/17] eventdev: " Lukasz Wojciechowski
2020-04-18  9:41       ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2020-04-18  9:53         ` Thomas Monjalon
2020-04-18 10:05           ` Jerin Jacob
2020-04-18 13:22             ` Thomas Monjalon
     [not found]   ` <CGME20200417215801eucas1p28aefc04e119aa5de16a7f0771bb0e268@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 05/17] fib: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215801eucas1p25e56a60eda9b741ba26e686b90ed8e28@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 06/17] cmdline: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215802eucas1p27d4041768b717226b7161d0b896c3261@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 07/17] hash: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215803eucas1p16013610674ce6ac58189259f2632f562@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 08/17] ip_frag: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215804eucas1p2c04d6f2141be07b25f0d346c73d4f965@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 09/17] lpm: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215805eucas1p114b3286afa16d6f12916048234f3a159@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 10/17] mbuf: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215805eucas1p2530efed5c5a73df8cc5fb613b11dfdde@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 11/17] mempool: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215806eucas1p1df0cf8a6cfe65dd687dde9056854bbad@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 12/17] power: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215807eucas1p14de926321e5a683224f7550ae902af5b@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 13/17] rcu: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215808eucas1p26bb784466131275eeccff018ecac83ca@eucas1p2.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 14/17] timer: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215808eucas1p1aa9a24a464a4470d27b6c770d2e8c297@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 15/17] vhost: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215809eucas1p1d826c921a9880007af4ee4282dda5d32@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 16/17] eal: " Lukasz Wojciechowski
     [not found]   ` <CGME20200417215810eucas1p17a63d33a4d49c8866733a33ce717484b@eucas1p1.samsung.com>
2020-04-17 21:57     ` [dpdk-dev] [PATCH v1 17/17] sched: " Lukasz Wojciechowski
2020-04-20  9:04       ` Dumitrescu, Cristian
     [not found]   ` <CGME20200422214613eucas1p153ed981de395ef1b800364a003da85e5@eucas1p1.samsung.com>
2020-04-22 21:45     ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
     [not found]       ` <CGME20200422214614eucas1p1044184e60bcb04469783ef0dd95091c1@eucas1p1.samsung.com>
2020-04-22 21:45         ` [dpdk-dev] [PATCH v2 1/3] config: introduce global rte " Lukasz Wojciechowski
2020-06-26 16:56           ` Bruce Richardson
2020-06-28  8:40             ` Andrew Rybchenko
2020-07-09 13:51             ` Lukasz Wojciechowski
2020-07-09 14:09               ` Bruce Richardson
2020-07-09 14:13                 ` Lukasz Wojciechowski
     [not found]       ` <CGME20200422214614eucas1p2ad5c7a54972cf47f182f51ba3346027b@eucas1p2.samsung.com>
2020-04-22 21:45         ` [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags Lukasz Wojciechowski
2020-06-26 16:56           ` Bruce Richardson
     [not found]       ` <CGME20200422214615eucas1p2a50ce20695a77b5b2888fd4521296094@eucas1p2.samsung.com>
2020-04-22 21:45         ` [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag Lukasz Wojciechowski
2020-06-26 17:00           ` Bruce Richardson
2020-07-09 13:50             ` Lukasz Wojciechowski
2020-04-24  9:09       ` [dpdk-dev] [PATCH v2 0/3] introduce global " Bruce Richardson
2020-04-24 10:14         ` Lukasz Wojciechowski
     [not found]       ` <CGME20200709134846eucas1p193d963c3f21f0d5c4985024b6d015042@eucas1p1.samsung.com>
2020-07-09 13:48         ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
     [not found]           ` <CGME20200709134847eucas1p2698cc0b2de3751aba984d306beb9d8f1@eucas1p2.samsung.com>
2020-07-09 13:48             ` [dpdk-dev] [PATCH v3 1/4] config: introduce global rte " Lukasz Wojciechowski
     [not found]           ` <CGME20200709134847eucas1p2c772544e09360a0b05e95e20c36fb0b8@eucas1p2.samsung.com>
2020-07-09 13:48             ` [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags Lukasz Wojciechowski
2020-07-16  7:43               ` David Marchand
2020-07-16  8:41                 ` Ruifeng Wang
     [not found]           ` <CGME20200709134848eucas1p1b78c9b2d4556ae3047d52e9d6e41b11c@eucas1p1.samsung.com>
2020-07-09 13:48             ` [dpdk-dev] [PATCH v3 3/4] mbuf: standardize library debug flag Lukasz Wojciechowski
     [not found]           ` <CGME20200709134848eucas1p27b4f137a91aa805e84f981802da2a226@eucas1p2.samsung.com>
2020-07-09 13:48             ` [dpdk-dev] [PATCH v3 4/4] app/test: add mbuf perf tests Lukasz Wojciechowski
2020-07-11 15:11           ` [dpdk-dev] [PATCH v3 0/4] introduce global debug flag Thomas Monjalon
2020-07-13  9:04             ` Bruce Richardson
2020-07-13 22:44               ` Lukasz Wojciechowski
2020-07-13 22:39             ` Lukasz Wojciechowski
2020-07-14  1:23               ` Stephen Hemminger

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=26026576.gRfpFWEtPU@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=evgenys@amazon.com \
    --cc=ferruh.yigit@intel.com \
    --cc=gtzalik@amazon.com \
    --cc=humin29@huawei.com \
    --cc=hyonkim@cisco.com \
    --cc=igor.russkikh@aquantia.com \
    --cc=igorch@amazon.com \
    --cc=jasvinder.singh@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=johndale@cisco.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=l.wojciechow@partner.samsung.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mk@semihalf.com \
    --cc=mw@semihalf.com \
    --cc=olivier.matz@6wind.com \
    --cc=pavel.belous@aquantia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=rmody@marvell.com \
    --cc=shshaikh@marvell.com \
    --cc=wenzhuo.lu@intel.com \
    --cc=xavier.huwei@huawei.com \
    --cc=xiao.w.wang@intel.com \
    --cc=xiaolong.ye@intel.com \
    --cc=xuanziyang2@huawei.com \
    --cc=yisen.zhuang@huawei.com \
    --cc=yongwang@vmware.com \
    --cc=zhihong.wang@intel.com \
    --cc=zhouguoyang@huawei.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).