From: Sunil Kumar Kori <skori@marvell.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/1] lib/librte_ip_frag: Remove PKT_TX_IP_CKSUM offload flags
Date: Tue, 16 Jul 2019 12:06:31 +0000 [thread overview]
Message-ID: <BN8PR18MB2691097E49BDE0AC4DCC34A6B4CE0@BN8PR18MB2691.namprd18.prod.outlook.com> (raw)
In-Reply-To: <26077215.QO4oM8pdKP@xps>
Regards
Sunil Kumar Kori
>-----Original Message-----
>From: Thomas Monjalon <thomas@monjalon.net>
>Sent: Tuesday, July 16, 2019 4:52 PM
>To: Sunil Kumar Kori <skori@marvell.com>
>Cc: dev@dpdk.org; Konstantin Ananyev <konstantin.ananyev@intel.com>;
>Jerin Jacob Kollanukkaran <jerinj@marvell.com>
>Subject: Re: [dpdk-dev] [PATCH v2 1/1] lib/librte_ip_frag: Remove
>PKT_TX_IP_CKSUM offload flags
>
>16/07/2019 08:23, Sunil Kumar Kori:
>> Currently PKT_TX_IP_CKSUM is being set into mbuf->ol_flags during
>> fragmentation operation implicitly by the library. Because of this,
>> application is forced to use checksum offload whether it is supported
>> by platform or not.
>>
>> Also documentation does not provide any expected value of ol_flags in
>> returned fragmented mbufs so application will never come to know that
>> which offloads are enabled. So transmission may be failed for the
>> platforms which does not support checksum offload.
>>
>> So removing mentioned flag from the library.
>>
>> Mentioned changeset is part of http://patches.dpdk.org/patch/53475/
>> Changes for reassembly operation is already accepcted. This patch set
>> implements the similar change for fragmentation operation.
>>
>> Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
>
>Sunil, I would really appreciate you take care of the formatting.
>The previous patch had a changed title to comply some coding style:
> e29fc4437 ip_frag: remove IP checkum offload flag
>It requires also this line:
> Fixes: e29fc44370c2 ("ip_frag: remove IP checkum offload flag") When
>sending a new version, you are supposed to:
> - add a changelog
> - use --in-reply-to
>
>Applied
>
Thanks.
Its my bad that I forgot to send next version with "--in-reply-to" and shared as a new patch.
I will take care of suggestions in future patches.
prev parent reply other threads:[~2019-07-16 12:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-16 6:23 Sunil Kumar Kori
2019-07-16 11:21 ` Thomas Monjalon
2019-07-16 12:06 ` Sunil Kumar Kori [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=BN8PR18MB2691097E49BDE0AC4DCC34A6B4CE0@BN8PR18MB2691.namprd18.prod.outlook.com \
--to=skori@marvell.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas@monjalon.net \
/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).