[dpdk-dev] [PATCH v3 08/16] fm10k: add Vector RX scatter function
Chen, Jing D
jing.d.chen at intel.com
Thu Oct 29 06:27:56 CET 2015
Hi, Steve,
Best Regards,
Mark
> -----Original Message-----
> From: Liang, Cunming
> Sent: Wednesday, October 28, 2015 10:30 PM
> To: Chen, Jing D; dev at dpdk.org
> Cc: Tao, Zhe; He, Shaopeng; Ananyev, Konstantin; Richardson, Bruce
> Subject: Re: [PATCH v3 08/16] fm10k: add Vector RX scatter function
>
> Hi Mark,
>
> On 10/27/2015 5:46 PM, Chen Jing D(Mark) wrote:
> > From: "Chen Jing D(Mark)" <jing.d.chen at intel.com>
> >
> > Add func fm10k_recv_scattered_pkts_vec to receive chained packets
> > with SSE instructions.
> >
> > Signed-off-by: Chen Jing D(Mark) <jing.d.chen at intel.com>
> > ---
> > drivers/net/fm10k/fm10k.h | 2 +
> > drivers/net/fm10k/fm10k_rxtx_vec.c | 88
> ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 90 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
> > index 1502ae3..06697fa 100644
> > --- a/drivers/net/fm10k/fm10k.h
> > +++ b/drivers/net/fm10k/fm10k.h
> > @@ -329,4 +329,6 @@ uint16_t fm10k_xmit_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
> > int fm10k_rxq_vec_setup(struct fm10k_rx_queue *rxq);
> > int fm10k_rx_vec_condition_check(struct rte_eth_dev *);
> > uint16_t fm10k_recv_pkts_vec(void *, struct rte_mbuf **, uint16_t);
> > +uint16_t fm10k_recv_scattered_pkts_vec(void *, struct rte_mbuf **,
> > + uint16_t);
> > #endif
> > diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
> b/drivers/net/fm10k/fm10k_rxtx_vec.c
> > index 2e6f1a2..3fd5d45 100644
> > --- a/drivers/net/fm10k/fm10k_rxtx_vec.c
> > +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
> > @@ -513,3 +513,91 @@ fm10k_recv_pkts_vec(void *rx_queue, struct
> rte_mbuf **rx_pkts,
> > {
> > return fm10k_recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts,
> NULL);
> > }
> > +
> > +static inline uint16_t
> > +fm10k_reassemble_packets(struct fm10k_rx_queue *rxq,
> > + struct rte_mbuf **rx_bufs,
> > + uint16_t nb_bufs, uint8_t *split_flags)
> > +{
> > + struct rte_mbuf *pkts[RTE_FM10K_MAX_RX_BURST]; /*finished
> pkts*/
> > + struct rte_mbuf *start = rxq->pkt_first_seg;
> > + struct rte_mbuf *end = rxq->pkt_last_seg;
> > + unsigned pkt_idx, buf_idx;
> > +
> > +
> > + for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
> > + if (end != NULL) {
> > + /* processing a split packet */
> > + end->next = rx_bufs[buf_idx];
> > + start->nb_segs++;
> > + start->pkt_len += rx_bufs[buf_idx]->data_len;
> > + end = end->next;
> > +
> > + if (!split_flags[buf_idx]) {
> > + /* it's the last packet of the set */
> > + start->hash = end->hash;
> > + start->ol_flags = end->ol_flags;
> > + pkts[pkt_idx++] = start;
> > + start = end = NULL;
> > + }
> > + } else {
> > + /* not processing a split packet */
> > + if (!split_flags[buf_idx]) {
> > + /* not a split packet, save and skip */
> > + pkts[pkt_idx++] = rx_bufs[buf_idx];
> > + continue;
> > + }
> > + end = start = rx_bufs[buf_idx];
> > + }
> I guess you forgot to consider the crc_len during processing. /Steve
In fm10k, crc is always be stripped and pkt_len/data_len carried actual
data length. So, we needn't add crc_len back here. This is a little different
from IXGBE.
More information about the dev
mailing list