[dpdk-dev] [PATCH v2 4/4] net/mlx4: add new Memory Region support

Nélio Laranjeiro nelio.laranjeiro at 6wind.com
Tue May 15 11:00:10 CEST 2018


On Thu, May 10, 2018 at 08:29:03PM +0100, Ferruh Yigit wrote:
> On 5/10/2018 7:01 AM, Yongseok Koh wrote:
> > 
> >> On May 9, 2018, at 8:00 PM, Yongseok Koh <yskoh at mellanox.com> wrote:
> >>
> >>
> >>> On May 9, 2018, at 4:12 PM, Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> >>>
> >>> On 5/9/2018 12:09 PM, Yongseok Koh wrote:
> >>> <...>
> >>>
> >>>> +/**
> >>>> + * Insert an entry to B-tree lookup table.
> >>>> + *
> >>>> + * @param bt
> >>>> + *   Pointer to B-tree structure.
> >>>> + * @param entry
> >>>> + *   Pointer to new entry to insert.
> >>>> + *
> >>>> + * @return
> >>>> + *   0 on success, -1 on failure.
> >>>> + */
> >>>> +static int
> >>>> +mr_btree_insert(struct mlx4_mr_btree *bt, struct mlx4_mr_cache *entry)
> >>>> +{
> >>>> +	struct mlx4_mr_cache *lkp_tbl;
> >>>> +	uint16_t idx = 0;
> >>>> +	size_t shift;
> >>>> +
> >>>> +	assert(bt != NULL);
> >>>> +	assert(bt->len <= bt->size);
> >>>> +	assert(bt->len > 0);
> >>>> +	lkp_tbl = *bt->table;
> >>>> +	/* Find out the slot for insertion. */
> >>>> +	if (mr_btree_lookup(bt, &idx, entry->start) != UINT32_MAX) {
> >>>> +		DEBUG("abort insertion to B-tree(%p):"
> >>>> +		      " already exist at idx=%u [0x%lx, 0x%lx) lkey=0x%x",
> >>>> +		      (void *)bt, idx, entry->start, entry->end, entry->lkey);
> >>>
> >>> This and various other logs causing 32bits build error because of %lx usage. Can
> >>> you please check them?
> >>>
> >>> I am feeling sad to complain a patch like this just because of log format issue,
> >>> we should find a solution to this issue as community, either checkpatch checks
> >>> or automated 32bit builds, I don't know.
> >>
> >> Bummer. I have to change my bad habit of using %lx. And we will add 32-bit build
> >> check to our internal system to filter this kind of mistakes beforehand.
> >>
> >> Will work with Shahaf to fix it and rebase next-net-mlx.
> > 
> > Ferruh, I've sent out a patch to Shahaf to change printing format specifiers and
> > Shahaf will squash it into the previous patches.
> > 
> > However, it seems we had stopped supporting 32-bit compilation since Nelio's
> > commit [1]
> > 
> > Not sure I'm doing right but I'm compiling it for T=i686-native-linuxapp-gcc and
> > still having a few more errors even except for my code. And even if I fix all of
> > the errors, linkage fails as explained in the commit message of [1].
> > 
> > Are you sure you encountered this 32b compilation issue for the first time?

On mlx5 32 bits has been disabled as Mellanox OFED does not support
32bits compilation whereas RDMA-Core supports it.

I've just taken a look on Mellanox Website, Mellanox OFED 4.3-3.0.2.1 is
still not available for 32bits.  We cannot assume the support exists.

> I do just compilation on mlx drivers.
> And building only mlx4 for 32bits, mlx5 doesn't support 32bits as you point out
> below patch. mlx4 32bit compiles fine with me as same config you have used.
> 
> Also features documentation [2] verifies this, mlx4 supports 32bits but mlx5 not.
> 
> [2]
> https://dpdk.org/browse/next/dpdk-next-net/tree/doc/guides/nics/features/mlx4.ini?h=v18.02#n32
> https://dpdk.org/browse/next/dpdk-next-net/tree/doc/guides/nics/features/mlx5.ini?h=v18.02#n42
> 
> > 
> > 
> > [1] http://dpdk.org/browse/dpdk/commit/?id=ebbb81eb27daca0a89ee8f228fcf141d9eb6ef1c
> > 
> > 
> > Thanks,
> > Yongseok
> > 
> > 
> 

-- 
Nélio Laranjeiro
6WIND


More information about the dev mailing list