DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Alex Kiselev <kiselev99@gmail.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] librte_ip_frag: mbuf count, expiration
Date: Tue, 15 May 2018 14:04:20 +0100	[thread overview]
Message-ID: <bd3ae1f9-5ec6-ea79-f460-a3cdfa46d9f3@intel.com> (raw)
In-Reply-To: <2310632874.20180514172345@gmail.com>

Hi Alex,

On 14-May-18 3:23 PM, Alex Kiselev wrote:
> Hi.
> 
> This patch adds two features to the librte_ip_frag library:

The commit message will be saved in git history for all eternity. I 
don't think it should start with "Hi", it's not an email :)

More to the point, generally, one patch == one fix/feature. Do not 
combine multiple features in one patch unless there's a very strong 
reason to do so (such as avoiding compilation breaks).

Your patch also lacks developer's certificate of origin (a sign-off), 
without which we cannot accept your patches into the codebase even if we 
really, really wanted to :)

Please refer to DPDK contribution guidelines on how to formulate and 
submit patches to DPDK community:

http://dpdk.org/doc/guides/contributing/patches.html

You are also adding new API calls. New API calls should be marked as 
"experimental" for at least one release as per our community guidelines:

http://dpdk.org/doc/guides/contributing/versioning.html

Also, new API's should be added to library's respective .map file to 
enable proper symbol exporting for shared library builds.

> 
> 1) it keeps track of number of mbufs holded in the fragmentation table.
>   rte_frag_table_mbuf_count()
> 
> There might be situations (kind of attack when a lot of fragmented packets are sent
> to a dpdk application in order to flood the fragmentation table) when no additional
> mbufs must be added to the fragmentations table since it already contains to many of them.
> Currently there is no way to determine the number of mbufs holded int the fragmentation table.
> 
> 2) Fragmented packets are supposed to live no longer than max_cycles, but the lib deletes an expired packet
> only occasionally when it scans a bucket to find an empty slot when adding a new packet.
> Therefore a fragment might sit in the table forever.
> 
> This patch add rte_frag_table_del_expired_entries() that scans list recently used packets
> and delete the expired ones.
> ---


-- 
Thanks,
Anatoly

      reply	other threads:[~2018-05-15 13:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 14:23 Alex Kiselev
2018-05-15 13:04 ` Burakov, Anatoly [this message]

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=bd3ae1f9-5ec6-ea79-f460-a3cdfa46d9f3@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=kiselev99@gmail.com \
    /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).