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 10:14:17 +0100	[thread overview]
Message-ID: <f9628aa1-ce18-870f-568c-c1676c883a06@yandex.ru> (raw)
In-Reply-To: <f42994d1-84e7-867b-168b-aa8660df8728@yandex.ru>

11/07/2022 00:35, Konstantin Ananyev пишет:
>  > 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)


Forgot to mention, new API has to be experimental.

>  > +{
>  > +    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-11  9:18 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
2022-07-11  9:14     ` Konstantin Ananyev [this message]
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=f9628aa1-ce18-870f-568c-c1676c883a06@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).