[dpdk-users] When do we get non-contiguous mbufs from rte_eth_rx_burst?

[dpdk-users] When do we get non-contiguous mbufs from rte_eth_rx_burst?

[Lazarenko, Vlad (WorldQuant)]

Hey everyone,

Does anyone happen to know if it is possible to receive non-contiguous mbufs from rte_eth_rx_burst? If so, when would this happen? I am thinking that NICs with LSO enabled could possibly do this if data does not fit into  RTE_MBUF_DEFAULT_BUF_SIZE? But if the packet fits, I don't see why the driver could possibly split that across multiple mbufs. Any insight is highly appreciated.

Thanks,
Vlad



###################################################################################

The information contained in this communication is confidential, may be

subject to legal privilege, and is intended only for the individual named.

If you are not the named addressee, please notify the sender immediately and

delete this email from your system.  The views expressed in this email are

the views of the sender only.  Outgoing and incoming electronic communications

to this address are electronically archived and subject to review and/or disclosure

to someone other than the recipient.

###################################################################################

Re: [dpdk-users] When do we get non-contiguous mbufs from rte_eth_rx_burst?

[Stephen Hemminger]

On Thu, 9 Feb 2017 22:17:56 +0000
"Lazarenko, Vlad (WorldQuant)" <Vlad.Lazarenko@worldquant.com> wrote:

> Hey everyone,
> 
> Does anyone happen to know if it is possible to receive non-contiguous mbufs from rte_eth_rx_burst? If so, when would this happen? I am thinking that NICs with LSO enabled could possibly do this if data does not fit into  RTE_MBUF_DEFAULT_BUF_SIZE? But if the packet fits, I don't see why the driver could possibly split that across multiple mbufs. Any insight is highly appreciated.
> 
> Thanks,
> Vlad


Any driver that handles jumbo frames is going to return a multiple segment mbuf when given
a mbuf pool with smaller buffers. It is common to create 2K mbuf pool and handle 9K frames.

> 
> ###################################################################################
> 
> The information contained in this communication is confidential, may be
> 
> subject to legal privilege, and is intended only for the individual named.
> 
> If you are not the named addressee, please notify the sender immediately and
> 
> delete this email from your system.  The views expressed in this email are
> 
> the views of the sender only.  Outgoing and incoming electronic communications
> 
> to this address are electronically archived and subject to review and/or disclosure
> 
> to someone other than the recipient.
> 
> ###################################################################################

Please don't use such Lawyer stuff on public mailing lists.
In fact according to the wording, it probably is against your rules for
me to respond to it.

Re: [dpdk-users] When do we get non-contiguous mbufs from rte_eth_rx_burst?

[Lazarenko, Vlad (WorldQuant)]

Stephen,

Got it. Thank you bunches!

- V

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, February 09, 2017 5:35 PM
> To: Lazarenko, Vlad (WorldQuant)
> Cc: users@dpdk.org
> Subject: Re: [dpdk-users] When do we get non-contiguous mbufs from
> rte_eth_rx_burst?
> 
> On Thu, 9 Feb 2017 22:17:56 +0000
> "Lazarenko, Vlad (WorldQuant)" <Vlad.Lazarenko@worldquant.com> wrote:
> 
> > Hey everyone,
> >
> > Does anyone happen to know if it is possible to receive non-contiguous
> mbufs from rte_eth_rx_burst? If so, when would this happen? I am thinking
> that NICs with LSO enabled could possibly do this if data does not fit into
> RTE_MBUF_DEFAULT_BUF_SIZE? But if the packet fits, I don't see why the
> driver could possibly split that across multiple mbufs. Any insight is highly
> appreciated.
> >
> > Thanks,
> > Vlad
> 
> 
> Any driver that handles jumbo frames is going to return a multiple segment
> mbuf when given a mbuf pool with smaller buffers. It is common to create
> 2K mbuf pool and handle 9K frames.
> 
> >
> >
> ###################################################################
> ###
> > #############
> >
> > The information contained in this communication is confidential, may
> > be
> >
> > subject to legal privilege, and is intended only for the individual named.
> >
> > If you are not the named addressee, please notify the sender
> > immediately and
> >
> > delete this email from your system.  The views expressed in this email
> > are
> >
> > the views of the sender only.  Outgoing and incoming electronic
> > communications
> >
> > to this address are electronically archived and subject to review
> > and/or disclosure
> >
> > to someone other than the recipient.
> >
> >
> ###################################################################
> ###
> > #############
> 
> Please don't use such Lawyer stuff on public mailing lists.
> In fact according to the wording, it probably is against your rules for me to
> respond to it.


###################################################################################

The information contained in this communication is confidential, may be

subject to legal privilege, and is intended only for the individual named.

If you are not the named addressee, please notify the sender immediately and

delete this email from your system.  The views expressed in this email are

the views of the sender only.  Outgoing and incoming electronic communications

to this address are electronically archived and subject to review and/or disclosure

to someone other than the recipient.

###################################################################################