> On Jan 20, 2017, at 4:08 PM, Ferruh Yigit <ferruh.yi...@intel.com> wrote: > > On 1/20/2017 12:19 AM, Ilya Matveychikov wrote: >> mi->next will be assigned to NULL few lines later, trivial patch >> >> Signed-off-by: Ilya V. Matveychikov <matvejchi...@gmail.com> >> --- >> lib/librte_mbuf/rte_mbuf.h | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >> index ead7c6e..5589d54 100644 >> --- a/lib/librte_mbuf/rte_mbuf.h >> +++ b/lib/librte_mbuf/rte_mbuf.h >> @@ -1139,7 +1139,6 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf >> *mi, struct rte_mbuf *m) >> mi->buf_addr = m->buf_addr; >> mi->buf_len = m->buf_len; >> >> - mi->next = m->next; > > Do you know why attaching mbuf is not supporting multi-segment? > Perhaps this can be documented in function comment, as one of the "not > supported" items.
No, I don’t know. For my application I’ve found that nb_segs with it’s limit in 256 segments is very annoying and I’ve decided not to use DPDK functions that dealt with nb_segs… But it is not about the rte_pktmbuf_attach() function and the patch. > Also, should we check mi->next before overwriting, in case it is not NULL? > >> mi->data_off = m->data_off; >> mi->data_len = m->data_len; >> mi->port = m->port; >> > I don’t know. It depends of the usage. Will someone needs to chain two chains of mbuf?
