[dpdk-dev] [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach

[Ilya Matveychikov]

> On Jan 20, 2017, at 4:08 PM, Ferruh Yigit <ferruh.yigit at 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 <matvejchikov at 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?