Hi, On Fri, Jan 11, 2019 at 01:48:12PM +0100, David Marchand wrote: > On Fri, Jan 11, 2019 at 12:57 PM Bruce Richardson < > bruce.richard...@intel.com> wrote: > > > On Fri, Jan 11, 2019 at 02:17:04PM +0300, Andrew Rybchenko wrote: > > > Olivier, David, > > > > > > could you take a look at naming suggested below and share your thoughts. > > > My fear is that rte_mbuf_buf_addr() is too generic and true for direct > > mbuf > > > only. That's why I'd like to highlight it in the function name. > > > > > > > I would tend to agree with that concern. > > > > I understand your concern as well. > > The only usecase we have so far is for drivers on the rx side, so > implicitely direct mbufs. > But from a api user pov, explicit is always better. > > I will let Olivier have the last word :-)
Thanks Andrew for pointing this out. However I agree with Yongseok: we already have many functions that applies to direct mbufs that don't have "direct" in their names. In my opinion, rte_mbuf_buf_addr() is a good name, but I think the doxygen comment could be improved a bit to state that it returns the pointer to the embedded data. I also think that a small comment explaining why the mp arg is required would be helpful. Thanks, Olivier
