DPDK patches and discussions
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
To: chcchc88@163.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] ip_frag: add IPv4 fragment copy packet API
Date: Mon, 11 Jul 2022 00:35:33 +0100	[thread overview]
Message-ID: <f42994d1-84e7-867b-168b-aa8660df8728@yandex.ru> (raw)
In-Reply-To: <1654784398-11315-1-git-send-email-chcchc88@163.com>

 > Some NIC drivers support MBUF_FAST_FREE(Device supports optimization
 > for fast release of mbufs. When set application must guarantee that
 > per-queue all mbufs comes from the same mempool and has refcnt = 1)
 > offload. In order to adapt to this offload function, add this API.
 > Add some test data for this API.
 >
 > Signed-off-by: Huichao Cai <chcchc88@163.com>
 > ---

...

 > --- a/lib/ip_frag/rte_ip_frag.h
 > +++ b/lib/ip_frag/rte_ip_frag.h
 > @@ -179,6 +179,32 @@ int32_t rte_ipv4_fragment_packet(struct rte_mbuf
 > *pkt_in,
 >               struct rte_mempool *pool_indirect);
 >
 >   /**
 > + * IPv4 fragmentation by copy.
 > + *
 > + * This function implements the fragmentation of IPv4 packets by copy.
 > + *
 > + * @param pkt_in
 > + *   The input packet.
 > + * @param pkts_out
 > + *   Array storing the output fragments.
 > + * @param nb_pkts_out
 > + *   The size of the array that stores the output fragments.
 > + * @param mtu_size
 > + *   Size in bytes of the Maximum Transfer Unit (MTU) for the outgoing
 > IPv4
 > + *   datagrams. This value includes the size of the IPv4 header.
 > + * @return
 > + *   Upon successful completion - number of output fragments placed
 > + *   in the pkts_out array.
 > + *   Otherwise - (-1) * errno.
 > + */
 > +__rte_experimental
 > +int32_t
 > +rte_ipv4_fragment_copy_packet(struct rte_mbuf *pkt_in,
 > +    struct rte_mbuf **pkts_out,
 > +    uint16_t nb_pkts_out,
 > +    uint16_t mtu_size);
 > +
 > +/**
 >    * This function implements reassembly of fragmented IPv4 packets.
 >    * Incoming mbufs should have its l2_len/l3_len fields setup correctly.
 >    *
 > diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c
 > b/lib/ip_frag/rte_ipv4_fragmentation.c
 > index a562424..9e050cc 100644
 > --- a/lib/ip_frag/rte_ipv4_fragmentation.c
 > +++ b/lib/ip_frag/rte_ipv4_fragmentation.c
 > @@ -262,3 +262,168 @@ static inline uint16_t
 > __create_ipopt_frag_hdr(uint8_t *iph,
 >
 >       return out_pkt_pos;
 >   }
 > +
 > +/**
 > + * IPv4 fragmentation by copy.
 > + *
 > + * This function implements the fragmentation of IPv4 packets by copy.
 > + *
 > + * @param pkt_in
 > + *   The input packet.
 > + * @param pkts_out
 > + *   Array storing the output fragments.
 > + * @param nb_pkts_out
 > + *   The size of the array that stores the output fragments.
 > + * @param mtu_size
 > + *   Size in bytes of the Maximum Transfer Unit (MTU) for the outgoing
 > IPv4
 > + *   datagrams. This value includes the size of the IPv4 header.
 > + * @return
 > + *   Upon successful completion - number of output fragments placed
 > + *   in the pkts_out array.
 > + *   Otherwise - (-1) * errno.
 > + */
 > +int32_t
 > +rte_ipv4_fragment_copy_packet(struct rte_mbuf *pkt_in,
 > +    struct rte_mbuf **pkts_out,
 > +    uint16_t nb_pkts_out,
 > +    uint16_t mtu_size)
 > +{
 > +    struct rte_mbuf *in_seg = NULL;
 > +    struct rte_ipv4_hdr *in_hdr;
 > +    uint32_t out_pkt_pos, in_seg_data_pos;
 > +    uint32_t more_in_segs;
 > +    uint16_t fragment_offset, flag_offset, frag_size, header_len;
 > +    uint16_t frag_bytes_remaining;
 > +    uint8_t ipopt_frag_hdr[IPV4_HDR_MAX_LEN];
 > +    uint16_t ipopt_len;
 > +
 > +    /*
 > +     * Formal parameter checking.
 > +     */
 > +    if (unlikely(pkt_in == NULL) || unlikely(pkts_out == NULL) ||
 > +        unlikely(nb_pkts_out == 0) ||
 > +        unlikely(pkt_in->pool == NULL) ||
 > +        unlikely(mtu_size < RTE_ETHER_MIN_MTU))
 > +        return -EINVAL;
 > +
 > +    in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
 > +    header_len = (in_hdr->version_ihl & RTE_IPV4_HDR_IHL_MASK) *
 > +        RTE_IPV4_IHL_MULTIPLIER;
 > +
 > +    /* Check IP header length */
 > +    if (unlikely(pkt_in->data_len < header_len) ||
 > +        unlikely(mtu_size < header_len))
 > +        return -EINVAL;
 > +
 > +    /*
 > +     * Ensure the IP payload length of all fragments is aligned to a
 > +     * multiple of 8 bytes as per RFC791 section 2.3.
 > +     */
 > +    frag_size = RTE_ALIGN_FLOOR((mtu_size - header_len),
 > +                    IPV4_HDR_FO_ALIGN);
 > +
 > +    flag_offset = rte_cpu_to_be_16(in_hdr->fragment_offset);
 > +
 > +    /* If Don't Fragment flag is set */
 > +    if (unlikely((flag_offset & IPV4_HDR_DF_MASK) != 0))
 > +        return -ENOTSUP;
 > +
 > +    /* Check that pkts_out is big enough to hold all fragments */
 > +    if (unlikely(frag_size * nb_pkts_out <
 > +        (uint16_t)(pkt_in->pkt_len - header_len)))
 > +        return -EINVAL;
 > +
 > +    in_seg = pkt_in;
 > +    in_seg_data_pos = header_len;
 > +    out_pkt_pos = 0;
 > +    fragment_offset = 0;
 > +
 > +    ipopt_len = header_len - sizeof(struct rte_ipv4_hdr);
 > +    if (unlikely(ipopt_len > RTE_IPV4_HDR_OPT_MAX_LEN))
 > +        return -EINVAL;
 > +
 > +    more_in_segs = 1;
 > +    while (likely(more_in_segs)) {
 > +        struct rte_mbuf *out_pkt = NULL;
 > +        uint32_t more_out_segs;
 > +        struct rte_ipv4_hdr *out_hdr;
 > +
 > +        /* Allocate buffer from pkt_in->pool*/
 > +        out_pkt = rte_pktmbuf_alloc(pkt_in->pool);


Instead of implicitly assuming that output mbufs will be allocated
from pkt_in pool, it would be better to have output_pool as explicit
parameter for that function.
In a same way we have it for rte_ipv4_fragment_packet().

 > +        if (unlikely(out_pkt == NULL)) {
 > +            __free_fragments(pkts_out, out_pkt_pos);
 > +            return -ENOMEM;
 > +        }
 > +
 > +        /* Reserve space for the IP header that will be built later */
 > +        out_pkt->data_len = header_len;
 > +        out_pkt->pkt_len = header_len;
 > +        frag_bytes_remaining = frag_size;
 > +
 > +        more_out_segs = 1;
 > +        while (likely(more_out_segs && more_in_segs)) {


If I understand correctly, here you assume that out_pkt will always
be big enough to hold entire fragment, right?
But that can not always be the case and probably we shouldn't assume
that for generic function.
I suppose safest way would be either use rte_pktmbuf_copy() here 
directly or do something similar to what that function doing ourselves here.


 > +            uint32_t len;
 > +
 > +            len = frag_bytes_remaining;
 > +            if (len > (in_seg->data_len - in_seg_data_pos))
 > +                len = in_seg->data_len - in_seg_data_pos;
 > +
 > +            rte_memcpy(
 > +                rte_pktmbuf_mtod_offset(
 > +                    out_pkt, char *, out_pkt->pkt_len),
 > +                rte_pktmbuf_mtod_offset(
 > +                    in_seg, char *, in_seg_data_pos),
 > +                len);
 > +            out_pkt->data_len = (uint16_t)(len +
 > +                out_pkt->data_len);
 > +
 > +            out_pkt->pkt_len = (uint16_t)(len +
 > +                out_pkt->pkt_len);
 > +            in_seg_data_pos += len;
 > +            frag_bytes_remaining -= len;
 > +
 > +            /* Current output packet (i.e. fragment) done ? */
 > +            if (unlikely(frag_bytes_remaining == 0))
 > +                more_out_segs = 0;
 > +
 > +            /* Current input segment done ? */
 > +            if (unlikely(in_seg_data_pos == in_seg->data_len)) {
 > +                in_seg = in_seg->next;
 > +                in_seg_data_pos = 0;
 > +
 > +                if (unlikely(in_seg == NULL))
 > +                    more_in_segs = 0;
 > +            }
 > +        }
 > +
 > +        /* Build the IP header */
 > +
 > +        out_hdr = rte_pktmbuf_mtod(out_pkt, struct rte_ipv4_hdr *);
 > +
 > +        __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len,
 > +            (uint16_t)out_pkt->pkt_len,
 > +            flag_offset, fragment_offset, more_in_segs);
 > +
 > +        if (unlikely((fragment_offset == 0) && (ipopt_len) &&
 > +                ((flag_offset & RTE_IPV4_HDR_OFFSET_MASK) == 0))) {
 > +            ipopt_len = __create_ipopt_frag_hdr((uint8_t *)in_hdr,
 > +                ipopt_len, ipopt_frag_hdr);
 > +            fragment_offset = (uint16_t)(fragment_offset +
 > +                out_pkt->pkt_len - header_len);
 > +            out_pkt->l3_len = header_len;
 > +
 > +            header_len = sizeof(struct rte_ipv4_hdr) + ipopt_len;
 > +            in_hdr = (struct rte_ipv4_hdr *)ipopt_frag_hdr;
 > +        } else {
 > +            fragment_offset = (uint16_t)(fragment_offset +
 > +                out_pkt->pkt_len - header_len);
 > +            out_pkt->l3_len = header_len;
 > +        }
 > +
 > +        /* Write the fragment to the output list */
 > +        pkts_out[out_pkt_pos] = out_pkt;
 > +        out_pkt_pos++;
 > +    }
 > +
 > +    return out_pkt_pos;
 > +}
 > diff --git a/lib/ip_frag/version.map b/lib/ip_frag/version.map
 > index e537224..4aa66bc 100644
 > --- a/lib/ip_frag/version.map
 > +++ b/lib/ip_frag/version.map
 > @@ -17,4 +17,5 @@ EXPERIMENTAL {
 >       global:
 >
 >       rte_ip_frag_table_del_expired_entries;
 > +    rte_ipv4_fragment_copy_packet;
 >   };

  reply	other threads:[~2022-07-10 23:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09  2:39 [PATCH v1] " Huichao Cai
2022-06-09 14:19 ` [PATCH v2] " Huichao Cai
2022-07-10 23:35   ` Konstantin Ananyev [this message]
2022-07-11  9:14     ` Konstantin Ananyev
2022-07-15  8:05       ` Huichao Cai
2022-07-19  8:19         ` Konstantin Ananyev
2022-07-22 13:01   ` [PATCH v3] " Huichao Cai
2022-07-22 14:42     ` Morten Brørup
2022-07-22 14:49     ` Stephen Hemminger
2022-07-22 15:52       ` Morten Brørup
2022-07-22 15:58         ` Huichao Cai
2022-07-22 16:14           ` Morten Brørup
2022-07-22 22:35             ` Konstantin Ananyev
2022-07-23  8:24               ` Morten Brørup
2022-07-23 18:25                 ` Konstantin Ananyev
2022-07-23 22:27                   ` Morten Brørup
2022-07-22 14:49     ` [PATCH v4] " Huichao Cai
2022-07-24  4:50       ` [PATCH v5] " Huichao Cai
2022-07-24  8:10         ` [PATCH v6] " Huichao Cai
2022-07-25 15:42           ` Stephen Hemminger
2022-07-26  1:22             ` Huichao Cai
2022-08-07 11:49               ` Konstantin Ananyev
2022-08-07 11:45           ` Konstantin Ananyev
2022-08-08  1:48           ` [PATCH v7] " Huichao Cai
2022-08-08 22:29             ` Konstantin Ananyev
2022-08-29 14:22               ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f42994d1-84e7-867b-168b-aa8660df8728@yandex.ru \
    --to=konstantin.v.ananyev@yandex.ru \
    --cc=chcchc88@163.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).