[dpdk-dev] [PATCH v2] net/i40e: remove weak symbols
On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote: Hi, Kiss > Using weak symbols have a few issues with static linking: > > - normally the linker searches the .o files already linked, if your weak > one is there, it won't check if there is a strong version > - unless the symbol is directly referred, but it's not the right thing to > rely on > - or --whole-archive specified in the command line, which pulls in a lot > of unwanted stuff --whole-archive on the other hand can ensure all the object files are linked, and the strong symbol will take precedence over weak symbol. So we don't need to take care of the sequence of the object files in the ar or between ar. > - whole-archive also makes libtool dropping the library from the command > line, which is what should happen with dynamic linking, but not with > static (observed on Ubuntu 14.04). This is an important bug if you > build a static library depending on DPDK you mean the libtool bug for --whole-archive? if it does, you shouldn't using the libtool, BTW what's the circumstance you must use the libtool. using you own makefile for the library or APP. > > This patch merges the two version and make the behaviour rely on the > config. > > If we can agree in the concept, I can send a series to fix this for the > other weak functions. > > Signed-off-by: Zoltan Kiss > --- > > Notes: > v2: fix commit message > > drivers/net/i40e/i40e_rxtx.c | 36 +++- > drivers/net/i40e/i40e_rxtx_vec.c | 36 > 2 files changed, 35 insertions(+), 37 deletions(-) > >From the original design, we follow the rule, we don't want the Macro in the >file to seperate the different Rx/Tx path for disabled/enabled vector configuration. Adam Bynes
[dpdk-dev] [PATCH] net/i40e: fix out-of-bounds writes during vector Rx
On Thu, Jul 21, 2016 at 02:03:38PM +0300, Ilya Maximets wrote:
> From: Sergey Dyasly
>
> Rx loop inside _recv_raw_pkts_vec() ignores nb_pkts argument and always
> tries to receive RTE_I40E_VPMD_RX_BURST (32) packets. This is a violation
> of rte_eth_rx_burst() API and can lead to memory corruption (out-of-bounds
> writes to struct rte_mbuf **rx_pkts) if nb_pkts is less than 32.
>
> Fix this by actually using nb_pkts inside the loop.
>
> Fixes: 9ed94e5bb04e ("i40e: add vector Rx")
>
> Signed-off-by: Sergey Dyasly
> Acked-by: Ilya Maximets
> ---
> drivers/net/i40e/i40e_rxtx_vec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec.c
> b/drivers/net/i40e/i40e_rxtx_vec.c
> index 05cb415..51fb282 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec.c
> @@ -269,7 +269,7 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
> rte_mbuf **rx_pkts,
>* D. fill info. from desc to mbuf
>*/
>
> - for (pos = 0, nb_pkts_recd = 0; pos < RTE_I40E_VPMD_RX_BURST;
> + for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
> pos += RTE_I40E_DESCS_PER_LOOP,
> rxdp += RTE_I40E_DESCS_PER_LOOP) {
> __m128i descs[RTE_I40E_DESCS_PER_LOOP];
> --
> 2.7.4
Acked-by: Adam Bynes
[dpdk-dev] [PATCH] eal: fix parsing of argument of option --lcores
On Thu, Jul 21, 2016 at 02:03:38PM +0800, Wei Dai wrote:
Hi Wei,
> The '-' in lcores set overrides cpu set of following
> lcore set in the argument of EAL option --lcores.
>
> Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
>
> Signed-off-by: Wei Dai
> ---
> lib/librte_eal/common/eal_common_options.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 0a594d7..96eb1a9 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -563,6 +563,7 @@ convert_to_cpuset(rte_cpuset_t *cpusetp,
> * lcores, cpus could be a single digit/range or a group.
> * '(' and ')' are necessary if it's a group.
> * If not supply '@cpus', the value of cpus uses the same as lcores.
> + * The 'a-b' in lcores not within '(' and ')' means a,a+1,...,b-1,b .
this description is not very clear, a-b and (a-b) are both the same meaning.
may be need a table for comparison
a-b@(c-d)
a-b at c-d
(a-b)@c-d
(a-b)@(c-d)
all the above I believe are the same
only the following two cases:
a-b,
(a-b),
so the key point here is the @ and (), not only @
> * e.g. '1,2@(5-7),(3-5)@(0,2),(0,6),7-8' means start 9 EAL thread as below
> * lcore 0 runs on cpuset 0x41 (cpu 0,6)
> * lcore 1 runs on cpuset 0x2 (cpu 1)
> @@ -571,6 +572,15 @@ convert_to_cpuset(rte_cpuset_t *cpusetp,
> * lcore 6 runs on cpuset 0x41 (cpu 0,6)
> * lcore 7 runs on cpuset 0x80 (cpu 7)
> * lcore 8 runs on cpuset 0x100 (cpu 8)
> + * e.g. '0-2,(3-5)@(3,4),6@(5,6),7@(5-7)'means start 8 EAL threads as below
> + * lcore 0 runs on cpuset 0x1 (cpu 0)
> + * lcore 1 runs on cpuset 0x2 (cpu 1)
> + * lcore 2 runs on cpuset ox4 (cpu 2)
> + * lcore 3,4,5 runs on cpuset 0x18 (cpu 3,4)
> + * lcore 6 runs on cpuset 0x60 (cpu 5,6)
> + * lcore 7 runs on cpuset 0xe0 (cpu 5,6,7)
> + * The second case is used to test bugfix for lflags not be cleared after use
you can put this sentance and description into the commit log
I don't think you should put bugfix description in comments here.
> + */
> */
> static int
> eal_parse_lcores(const char *lcores)
> @@ -679,6 +689,8 @@ eal_parse_lcores(const char *lcores)
> sizeof(rte_cpuset_t));
> }
>
> + lflags = 0;
> +
> lcores = end + 1;
> } while (*end != '\0');
>
> --
> 2.5.5
Adam Bynes
