All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huichao Cai" <chcchc88@163.com>
To: "Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>
Cc: dev@dpdk.org
Subject: Re:Re: [PATCH v2] ip_frag: add IPv4 fragment copy packet API
Date: Fri, 15 Jul 2022 16:05:28 +0800 (CST)	[thread overview]
Message-ID: <382d9871.2d7c.18200e4265e.Coremail.chcchc88@163.com> (raw)
In-Reply-To: <f9628aa1-ce18-870f-568c-c1676c883a06@yandex.ru>

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

Hi Konstantin,


    I've been busy lately, sorry to reply to you late.


    > 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 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.
reply: Thanks for the reminder, I will use explicit parameters and rte_pktmbuf_copy();
> Forgot to mention, new API has to be experimental.
reply: Does this mean adding _rte_experimental when declaring a function?


Huichao,Cai

[-- Attachment #2: Type: text/html, Size: 4648 bytes --]

  reply	other threads:[~2022-07-15  8:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09  2:39 [PATCH v1] ip_frag: add IPv4 fragment copy packet API 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
2022-07-15  8:05       ` Huichao Cai [this message]
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=382d9871.2d7c.18200e4265e.Coremail.chcchc88@163.com \
    --to=chcchc88@163.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.v.ananyev@yandex.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.