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 <ys...@mellanox.com> wrote: > >> > >> > >>> On May 9, 2018, at 4:12 PM, Ferruh Yigit <ferruh.yi...@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