> -Original Message-
> From: Hemant Agrawal [mailto:hemant.agra...@nxp.com]
> Sent: Friday, September 27, 2019 5:05 AM
> To: dev@dpdk.org
> Cc: Legacy, Allain; Peters, Matt; Hemant Agrawal
> Subject: [PATCH] doc: replace license text with SPDX tag for AVP nic
>
>
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Monday, August 19, 2019 7:42 AM
> To: dev@dpdk.org
> Cc: John W. Linville; Xiaolong Ye; Qi Zhang; Igor Russkikh; Pavel Belous;
> Legacy, Allain; Peters, Matt; Ravi Kumar; Rasesh Mody; S
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Monday, March 04, 2019 6:18 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Legacy, Allain; Peters, Matt
> Subject: [PATCH 02/12] net/avp: fix incorrect rxq errors stat
>
> Tra
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, November 26, 2018 12:11 PM
> To: Legacy, Allain; Peters, Matt; Ravi Kumar; Declan Doherty; Chas Williams;
> Cristian Dumitrescu; Fiona Trahe; Pablo de Lara; Ashish Gupta; Konstantin
&
> -Original Message-
> From: Agalya Babu RadhaKrishnan
> [mailto:agalyax.babu.radhakrish...@intel.com]
> Sent: Wednesday, October 03, 2018 10:00 AM
> To: dev@dpdk.org
> Cc: alejandro.luc...@netronome.com; Legacy, Allain;
> jasvinder.si...@intel.com; keit
on; Ori Kam; Bruce
> Richardson; Pablo de Lara; Radu Nicolau; Akhil Goyal; Tomasz Kantecki; John
> W. Linville; Legacy, Allain; Peters, Matt; Ravi Kumar; Ajit Khaparde; Somnath
> Kotur; Rahul Lakkireddy; Hemant Agrawal; Shreyansh Jain; John Daley; Hyong
> Youb Kim; Gaetan Rivet; Beilei X
> -Original Message-
> From: santosh [mailto:santosh.shu...@caviumnetworks.com]
> Sent: Thursday, August 30, 2018 8:59 AM
> To: hemant.agra...@nxp.com; Gaëtan Rivet; Burakov, Anatoly
> Cc: Zhang, Qing Long (Eric); bruce.richard...@intel.com; dev@dpdk.org;
> Legacy, Al
> -Original Message-
> From: Tiwei Bie [mailto:tiwei@intel.com]
> Sent: Tuesday, August 14, 2018 11:40 PM
> To: Legacy, Allain
> Cc: maxime.coque...@redhat.com; zhihong.w...@intel.com;
> dev@dpdk.org; Peters, Matt; Zhang, Qing Long (Eric)
> Subject: Re: [PATCH] n
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Tuesday, June 19, 2018 2:03 PM
<...>
> Subject: [PATCH] ethdev: add new offload flag to keep CRC
>
> DEV_RX_OFFLOAD_KEEP_CRC offload flag added. PMDs that supports
> keeping CRC should advertise this offload
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, June 08, 2018 12:38 PM
> To: dev@dpdk.org
> Cc: RICHARDSON, BRUCE; Legacy, Allain
> Subject: [PATCH 7/7] net/avp: fix 32-bit meson builds
>
> When compiling with m
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Thursday, May 17, 2018 4:15 PM
> To: dev@dpdk.org
> Cc: RICHARDSON, BRUCE; Legacy, Allain; Peters, Matt
> Subject: [PATCH-18.08 02/15] net/avp: add to meson build
>
> Signed-
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Wednesday, April 11, 2018 7:02 AM
<..>
>
>
> I wonder why we have to NULL only first and cur entry?
> We probably have to NULL each one in that case, right?
We have to do first and current entr
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Tuesday, March 27, 2018 1:41 PM
<...>
> Subject: [PATCH] ethdev: replace bus specific struct with generic dev
>
> Public struct rte_eth_dev_info has a "struct rte_pci_device" field in it
> although it is comm
> -Original Message-
> From: Yongseok Koh [mailto:ys...@mellanox.com]
> Sent: Thursday, March 22, 2018 7:38 PM
<..>
> >
> > Signed-off-by: Allain Legacy
> > Signed-off-by: Nelio Laranjeiro
> > ---
>
> Dahir, Allain
>
> Did you get a chance to test this patch? It would be good to have '
> -Original Message-
> From: Yongseok Koh [mailto:ys...@mellanox.com]
> Sent: Thursday, March 22, 2018 7:38 PM
<..>
>
> Dahir, Allain
>
> Did you get a chance to test this patch? It would be good to have 'tested-by'
> tag from you.
I will be able to test it early next week.
Allain
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Wednesday, March 21, 2018 4:34 AM
<...>
> The engine is not trivial as it needs to convert flow API to Verbs flows which
> the restrictions from the MLX5 kernel driver.
> Trying to give instructions e
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Tuesday, March 20, 2018 8:26 AM
...
>
> Unfortunately, is not enough to have a valid RSS hash result when the PMD
> has a single Rx queue, a little more work needs to be handled in the
> mlx5_flow.c e
> -Original Message-
> From: Van Haaren, Harry [mailto:harry.van.haa...@intel.com]
> Sent: Thursday, January 25, 2018 12:06 PM
> Subject: RE: [PATCH 06/18] net/avp: align dynamic log names with standard
>
> > From: Legacy, Allain [mailto:allain.leg...@windriver.co
> -Original Message-
> From: Harry van Haaren [mailto:harry.van.haa...@intel.com]
> Sent: Thursday, January 25, 2018 4:01 AM
> Subject: [PATCH 06/18] net/avp: align dynamic log names with standard
>
> This commit aligns the names for dynamic logging with the newly defined
> logging format.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Friday, September 01, 2017 4:06 AM
> To: dev@dpdk.org
> Cc: Gaëtan Rivet; Legacy, Allain
> Subject: [PATCH v2 03/51] net/mlx4: check max number of ports dynamically
>
> Use
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Tuesday, August 01, 2017 12:54 PM
<...>
> @@ -5946,12 +5949,11 @@ mlx4_arg_parse(const char *key, const char *val,
> void *out)
> return -errno;
> }
> if (strcmp(MLX4_PMD_PORT
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Sunday, June 04, 2017 12:21 PM
<..>
> >
> > +/* delete fragmentation table */
> > +void
> > +rte_ip_frag_table_destroy(struct rte_ip_frag_tbl *tbl)
> > +{
> > + uint32_t i;
> > +
> > + for (i
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, May 25, 2017 1:53 PM
> To: Legacy, Allain; Peters, Matt
> Cc: dev@dpdk.org; YIGIT, FERRUH
> Subject: [PATCH] net/avp: remove redundant assignment
>
> dev_info->
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Friday, May 12, 2017 6:33 AM
> To: John W. Linville; Legacy, Allain; Peters, Matt; Harish Patil; Rasesh Mody;
> Stephen Hurd; Ajit Khaparde; DOHERTY, DECLAN; LU, WENZHUO; Marcin
> Wojtas; Mi
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, May 04, 2017 9:08 AM
> To: Thomas Monjalon; Shepard Siegel; Ed Czeck; John Miller; Legacy, Allain;
> Peters, Matt; LU, WENZHUO; ZHANG, HELIN; WU, JINGJING; ANANYEV,
> KONSTANTIN
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Friday, April 28, 2017 2:49 AM
> To: Peters, Matt
> Cc: dev@dpdk.org; YIGIT, FERRUH
> Subject: [PATCH] net/avp: fix interrupt migration check
>
> Bitwise OR within if statement is always true, fix bitwise ope
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Tuesday, April 25, 2017 10:49 AM
<...>
> > Thank you.
>
> Can I add your acked-by line directly assuming all the above is done as
> described?
Yes.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Tuesday, April 25, 2017 8:50 AM
<...>
> > 2) RTE_STD_C11 needs to be included in the #ifdef __KERNEL__.
>
> Missed that one, however I suggest either:
>
> #ifndef __KERNEL__ around RTE_STD_C11
>
>
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Tuesday, April 25, 2017 4:30 AM
<...>
>
> +#include
> #ifdef __KERNEL__
> #include
> +#else
> +#include
> +#include
> +#include
> +#include
> +#endif
I compiled this in our environment and fo
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Monday, April 24, 2017 11:53 AM
<...>
> diff --git a/drivers/net/avp/rte_avp_common.h
> b/drivers/net/avp/rte_avp_common.h
> index 31d763e..6cdaca9 100644
> --- a/drivers/net/avp/rte_avp_common.h
> ++
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Monday, April 24, 2017 1:47 AM
<...>
> > nmb = rte_mbuf_raw_alloc(rxq->mp);
> > - if (unlikely(!nmb))
> > + if (unlikely(!nmb)) {
> > + PMD_RX_LOG(DEBUG, "RX m
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet
> Sent: Tuesday, April 11, 2017 11:45 AM
> To: dev@dpdk.org
> Cc: Jan Blunck
> Subject: [dpdk-dev] [PATCH v2 36/42] net/avp: Don't use eth_driver
>
> Signed-off-by: Gaetan Rivet
> ---
Acked-by: Allai
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, April 06, 2017 10:43 AM
<...>
> You are facing some kind of issue?
Ok, thanks for the clarification. No, I am no longer experiencing an issue...
the problem was between the keyboard and t
Hi,
None of the comments in the rte_flow.h file (or the programmers guide) specify
what endianness should be applied to spec/mask fields. Based on the testing I
have done so far using a CX4 device (mlx5 driver) fields like VLAN ID and UDP
ports are expected in network byte order. There seems t
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Tuesday, April 04, 2017 1:12 PM
<...>
>
> Right now compiler config files only have compiler and architecture configs,
> although it is OK to update them, to be consistent with what other PMDs did,
> what do
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Monday, April 03, 2017 10:22 AM
<...>
>
> If that is the case then Please send a patch to fix it appropriately.
Will do, thanks for fixing this error.
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Monday, April 03, 2017 9:59 AM
> To: dev@dpdk.org
> Cc: YIGIT, FERRUH; Legacy, Allain; Jerin Jacob
> Subject: [dpdk-dev] [PATCH] net/avp: fix build with non x86
>
> sys/io.h i
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Friday, March 31, 2017 4:35 AM
<...>
> + Olga Shern,
>
> Allain,
>
> Thanks for all this tests, for this last point is seems to be a firmware or
> hardware issue, I don't have any way to help on that
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Friday, March 31, 2017 6:08 AM
<...>
> > + * @return
> > + * Handle to configuration file on success, NULL otherwise
> > + * @param
>
> This @param should be removed.
Ok. I will remove it.
>
> >
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, March 30, 2017 9:03 AM
<...>
> I found an issue on the id retrieval while receiving an high rate of the
> same flow [1]. You may face the same issue. Can you verify with the
> patch?
>
>
> -Original Message-
> From: Zhang, Helin [mailto:helin.zh...@intel.com]
> Sent: Tuesday, March 28, 2017 4:52 AM
<...>
> > +
> > + dev = &rte_eth_devices[rxq->port_id];
> > + dev->data->rx_mbuf_alloc_failed += rxq-
> > >rx_free_thresh;
> > +
> I think th
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> Sent: Wednesday, March 29, 2017 3:02 AM
<...>
>
> OTOH, it's still good to have RTE_LOG_ONCE. It explicitly tells you something
> is wrong, then you could dump those stats for more info.
Has the implementatio
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Wednesday, March 29, 2017 5:45 AM
<...>
> > Almost... the only difference is that the ETH pattern also checks for
> type=0x8100
>
> Ethernet type was not supported in DPDK 17.02, it was submitted lat
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Sent: Wednesday, March 29, 2017 5:33 AM
<...>
>
> Can we please add a test to check that error is triggered for keys defined
> outside any section when the CFG_FLAG_GLOBAL_SECTION is NOT provided
>
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Sent: Wednesday, March 29, 2017 5:31 AM
<...>
> > +#define CFG_FLAG_EMPTY_VALUES (1 << 1)
> > /**@} */
> >
>
> I suggest we group all these flags into an (unnamed?) enum in rte_cfgfile.h
> rather t
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Sent: Wednesday, March 29, 2017 5:23 AM
> >
> > +/** Configuration file operation optional arguments */ struct
> > +rte_cfgfile_parameters {
> > + char comment_character;
> > + /**< Config file co
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Tuesday, March 28, 2017 11:36 AM
<..>
> If I understand correctly, your application is adding 500 rules like:
>
> flow create 0 ingress pattern eth src is dst is / vlan vid is
> / end action mark
Hi,
I am setting up an experiment to gauge the usability of the flow API and the
flow marking behavior of the CX4. I am working from v17.02. I am seeing
some unpredictable behavior that I am unsure of the cause.
This is the layout of the test:
2 x CX4 (15b3:1015)
+ 1 port used
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> Sent: Tuesday, March 28, 2017 2:49 AM
<...>
> > In order to prevent this condition, but
> > still enable debugging, the logs are being changed to debug logs to ensure
> > they are not emitted unless the CONFIG_R
> -Original Message-
> From: Legacy, Allain
> Sent: Monday, March 27, 2017 7:13 AM
> To: DUMITRESCU, CRISTIAN FLORIN; RICHARDSON, BRUCE
> Cc: yuanhan@linux.intel.com; dev@dpdk.org
> Subject: RE: [PATCH v2 6/6] cfgfile: add support for empty value string
>
&g
ain.legacy
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Sent: Monday, March 27, 2017 6:55 AM
> To: Legacy, Allain; RICHARDSON, BRUCE
> Cc: yuanhan@linux.intel.com; dev@dpdk.org
> Subject: RE: [PATCH v2 6/6] cfgfile: add su
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, March 23, 2017 10:18 AM
<...>
> Hi Allain,
>
> Overall PMD looks good to me.
>
> Only can you please update documentation based on tech board decision [1].
>
> Repeating related part here:
> "
>
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Friday, March 17, 2017 4:49 AM
<...>
> I think there is one interesting technological point in this thread.
> We are discussing about IVSHMEM but its support by Qemu is confused.
> This feature is not
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, March 16, 2017 10:53 AM
<...>
> +;
> > +[Features]
> > +Link status = Y
> > +Queue start/stop = Y
> > +Jumbo frame = Y
> > +Scattered Rx = Y
> > +Promiscuous mode
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, March 16, 2017 10:53 AM
<...>
> I am for removing static function declarations by reordering functions, and
> for this case even reordering not required I think, you can remove them.
Ok. Will do
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Thursday, March 16, 2017 10:53 AM
<..>
> Hi Allain,
>
> Instead of adding files per patch, may I suggest different ordering:
> First add skeleton files in a patch, later add functional pieces one by one,
incent JARDIN [mailto:vincent.jar...@6wind.com]
> Sent: Friday, March 03, 2017 11:22 AM
> To: Legacy, Allain; YIGIT, FERRUH
> Cc: Jolliffe, Ian; jerin.ja...@caviumnetworks.com;
> step...@networkplumber.org; thomas.monja...@6wind.com;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [P
> -Original Message-
> From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com]
> Sent: Friday, March 10, 2017 12:12 PM
> The first solution might be interesting, however it makes this option
> dependent on two defines instead of one. If one had to change the
> default MAX_PHYS_PORT value for mlx
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet
> Sent: Friday, March 03, 2017 10:40 AM
...
> + errno = 0;
> + tmp = strtoul(val, NULL, 0);
The robustness of the strtoul() could be improved with something like the
following to catch non-inte
> -Original Message-
> From: Wiles, Keith [mailto:keith.wi...@intel.com]
> Sent: Thursday, March 09, 2017 8:46 AM
> Would this change still cause a failure and memory over write if the user
> decides to have very large string. Does the code check the lengths to make
> sure they are valid an
> -Original Message-
> From: Legacy, Allain
> > From: Chas Williams [mailto:3ch...@gmail.com]
> > I don't see the other side of this to unregister the callback. It's also a
> > bit
> > confusing with this here and the other parts in part 15. It
> -Original Message-
> From: Chas Williams [mailto:3ch...@gmail.com]
> I don't see the other side of this to unregister the callback. It's also a
> bit
> confusing with this here and the other parts in part 15. It looks like you
> enable the interrupts on .dev_create but disable on .dev_
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>
> The second goto is unnecessary.
Ok. Will remove.
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Memset here is unnecessary since only caller is rte_eth_stats_get() which
> already did memset
>
Ok. Will remove.
> -Original Message-
> From: Chas Williams [mailto:3ch...@gmail.com]
> > + */
> > +#ifndef RTE_AVP_ALIGNMENT
> > +#define RTE_AVP_ALIGNMENT 64
> > +#endif
>
> This is already provided by DPDK as CONFIG_RTE_CACHE_LINE_SIZE
We took another look at our usage of this. We need it for another
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> I disagree here. I think we must control the set of allowed separators to
> avoid confusion.
I don't understand. What will be confusing? The app owns the file format and
is responsible to ensure th
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Also, for a single parameter like a comment char, I don't think we need to go
> creating a separate structure. The current flags parameter is unused, so just
> replace it with the comment char one. With usi
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Both approaches can support this. Therefore, IMO the separator char is not
> enough to justify approach 1. I would only go for approach 1 if there are
> some other parameters that we could consider
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> Possible options that I see:
> 1. Add a new parameters argument to the load functions (e.g. struct
> cfgfile_params *p), whit the comment char as one (and currently only) field
> of this struct. Drawb
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
>
> I am not totally against it, but IMO this option is a bit confusing. Again,
> what's
> wrong with user explicitly adding the GLOBAL section if needed?
There's nothing wrong with using a global sec
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
>
> What is the motivation for the having key/value pair outside of any section?
> What would be the drawback of having the user explicitly define a GLOBAL
> section to host these key/value pairs?
Glob
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> We are trying to avoid adding in extra build-time options to DPDK, so
> can you please rework this patch to make it a run-time option instead.
> Perhaps just add a set_comment_char() API call to the library
Please ignore.
Allain Legacy, Software Developer
direct 613.270.2279 fax 613.492.7870 skype allain.legacy
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Allain Legacy
> Sent: Wednesday, March 01, 2017 12:42 PM
> To: thomas.monja...@6wind.com
> Cc: dev@dpd
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>
> In checkpatch source there is a regex to identify logging functions and
> special
> exceptions for long lines etc. But the logging functions are for kernel
> (printk
> etc), not DPDK logging functions
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> > WARNING:LONG_LINE_STRING: line over 80 characters
> > #120: FILE: drivers/net/avp/avp_ethdev.c:236:
> > + PMD_DRV_LOG(ERR, "Timeout while waiting for a
> response for %u\n",
> >
>
> There
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > +/* Ethernet device validation marker */ #define
> RTE_AVP_ETHDEV_MAGIC
> > +0x92972862
>
> I think, we don't need to add RTE_ for internal flags and PMD APIs etc.
Ok, will rename.
> > +/* 32-bit MMIO reg
> > +#ifndef RTE_AVP_ALIGNMENT
> > +#define RTE_AVP_ALIGNMENT 64
>
> I think we use RTE_CACHE_LINE_SIZE here? PPC and ThunderX1 targets are
> cache line size of 128B
We need this to stay aligned with our host compile environment so we are going
to retain this as a local value instead of relying o
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> In my experience, checkpatch ignores long lines that are due to error
> messages. Perhaps you need to put the error message on a separate line,
> if other things before the message are of significant size.
I
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>
> PCI table should be const
Ok. Will do.
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>
> What exactly is the spinlock protecting? The control operations in DPDK are
> defined to be not thread safe. I.e it is responsibility of caller to
> synchronize.
> Therefore is lock really needed?
The
> -Original Message-
> From: Mcnamara, John [mailto:john.mcnam...@intel.com]
>
> The patchset should also include an update to the release notes:
>
> doc/guides/rel_notes/release_17_05.rst
>
Ok. will do.
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> On Sun, 26 Feb 2017 14:08:59 -0500
> Allain Legacy wrote:
>
> Try not to break error messages onto two lines, it makes it harder when a
> user is trying to find the location of the error message with sea
> -Original Message-
> From: Vincent JARDIN [mailto:vincent.jar...@6wind.com]
...
> So, before spending too much time in reviewing your long serie, I think that
> proper statements are needed. In the past, other NICs using Qemu have
> been sent, but they were avoided since virtio solved all
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Allain Legacy
> Sent: Sunday, February 26, 2017 2:09 PM
> To: YIGIT, FERRUH
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 12/15] net/avp: packet transmit functions
>
> Adds support for packet transmit function
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Sunday, February 26, 2017 11:42 AM
> To: Legacy, Allain
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] checkpatch.pl inconsistent results
...
> Yes it has been discussed few tim
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Sunday, February 26, 2017 4:12 AM
> To: Legacy, Allain
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] checkpatch.pl inconsistent results
> Importance: High
>
> 2017-
Hi,
I sent a patchset to the to the mailing list last night for which I received
several coding style warnings. Having discovered that I was using an older
version of checkpatch.pl I downloaded the latest and set out to fix the
warnings. The tool is flagging the usage of PRIx64 and PRIu64 in
87 matches
Mail list logo
