From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>,
Yong Wang <yongwang@vmware.com>,
"Liu, Jijiang" <jijiang.liu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload
Date: Wed, 12 Nov 2014 09:55:44 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258213A3F5F@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <5460E07F.6060303@6wind.com>
Hi Oliver,
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Monday, November 10, 2014 3:58 PM
> To: Ananyev, Konstantin; Yong Wang; Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload
>
> Hello Konstantin,
>
> >> By the way, we had the same kind of discussion with Konstantin [1]
> >> about what to do with the TCP checksum. My feeling is that setting it
> >> to the pseudo-header checksum is the best we can do:
> >> - linux does that
> >> - many hardware requires that (this is not the case for ixgbe, which
> >> need a pshdr checksum without the IP len)
> >> - it can be reused if received by a virtual device and sent to a
> >> physical device supporting TSO
> >
> > Yes, I remember that discussion.
> > I still think we better avoid any read/write access of the packet data inside PMD TX routine.
> > (packet header parsing and/or pseudo-header checksum calculations).
> > As I said before - if different HW have different requirements of what have to be recalculated for HW TX offloads -
> > why not introduce a new function dev_prep_tx(portid, queueid, mbuf[], num)?
> > PMD developer can put all necessary calculations/updates of the packet data and related mbuf fields inside that function.
> > It would be then a PMD responsibility to provide that function and it would be an app layer responsibility to call it for
> > mbufs with TX offload flags before calling tx_burst().
>
> I think I understand your point: you don't want to touch the packet
> in the PMD because the lcore that transmits the packet can be different
> than the one that built it. In this case (i.e. a pipeline case),
> reading or writing the packet can produce a cache miss, is it correct?
Yes, it is correct.
That's one of the main reason why current implementations of TX routines avoid touching packet data.
> From an API perspective, it looks a bit more complex to have to call
> dev_prep_tx() before sending the packets if they have been flagged
> for offload processing. But I admit I have no other argument. I'll be
> happy to have more comments from other people on the list.
>
> I'm sending a first version of the patchset now as it's ready, it does
> not take in account this comment, but I'm open to add it in a v2 if
> there is a consensus on this.
>
> Now, knowing that:
> - adding dev_prep_tx() will also concern hw checksum (TCP L4 checksum
> already requires to set the TCP pseudo header checksum), so adding
> this will change the API of an existing feature
> - TSO is a new feature expected for 1.8 (which should be out soon)
>
> Do you think we need to include this for 1.8 or can we postpone your
> proposition for after the 1.8 release?
I'd say it would be good to have it done together with TSO feature.
About changing API: I think existing applications shouldn't be affected.
For existing PMDs/TX offloads we don't change any rules what need to be filled by the app.
We just add a new function that can do that for user.
If the app fills required manually (as all apps have to do now) it would keep working as expected.
If you feel like it is too much work for 1.8 timeframe -
can we at least move fix_tcp_phdr_cksum() out of TX PMD as a temporary measure?
Let say create a function get_ipv4_udptcp_checksum(struct rte_mbuf *m) (in librte_net ?).
It will calculate PSD checksum for both TSO and non-TSO case based on given mbuf flags/fields.
Then we can update testpmd/csumonly.c to use it.
Thanks
Konstantin
> Thank you for your comments,
> Regards,
> Olivier
>
>
>
> >> [1] http://dpdk.org/ml/archives/dev/2014-May/002766.html
next prev parent reply other threads:[~2014-11-12 9:47 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 2:13 [dpdk-dev] [PATCH v8 00/10] Support VxLAN on Fortville Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 01/10] librte_mbuf:the rte_mbuf structure changes Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 02/10] librte_ether:add the basic data structures of VxLAN Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 03/10] librte_ether:add VxLAN packet identification API Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 04/10] i40e:support VxLAN packet identification in i40e Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 05/10] app/test-pmd:test VxLAN packet identification Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 06/10] librte_ether:add data structures of VxLAN filter Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 07/10] i40e:implement the API of VxLAN filter in librte_pmd_i40e Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 08/10] app/testpmd:test VxLAN packet filter Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 09/10] i40e:support VxLAN Tx checksum offload Jijiang Liu
2014-10-27 2:13 ` [dpdk-dev] [PATCH v8 10/10] app/testpmd:test " Jijiang Liu
2014-11-04 8:19 ` Olivier MATZ
2014-11-05 6:02 ` Liu, Jijiang
2014-11-05 10:28 ` Olivier MATZ
2014-11-06 11:24 ` Liu, Jijiang
2014-11-06 13:08 ` Olivier MATZ
2014-11-06 14:27 ` Liu, Jijiang
2014-11-07 0:43 ` Yong Wang
2014-11-07 17:16 ` Olivier MATZ
2014-11-10 11:39 ` Ananyev, Konstantin
2014-11-10 15:57 ` Olivier MATZ
2014-11-12 9:55 ` Ananyev, Konstantin [this message]
2014-11-12 13:05 ` Olivier MATZ
2014-11-12 13:40 ` Thomas Monjalon
2014-11-12 23:14 ` Ananyev, Konstantin
2014-11-12 14:39 ` Ananyev, Konstantin
2014-11-12 14:56 ` Olivier MATZ
[not found] ` <D0868B54.24DBB%yongwang@vmware.com>
2014-11-11 0:07 ` [dpdk-dev] FW: " Yong Wang
2014-11-10 6:03 ` [dpdk-dev] " Liu, Jijiang
2014-11-10 16:17 ` Olivier MATZ
[not found] ` <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8F7A7@SHSMSX101.ccr.corp.intel.com>
2014-11-12 17:26 ` Thomas Monjalon
2014-11-13 5:35 ` Liu, Jijiang
2014-11-13 5:39 ` Liu, Jijiang
2014-11-13 6:51 ` Liu, Jijiang
2014-11-13 9:10 ` Thomas Monjalon
2014-11-14 8:15 ` Liu, Jijiang
2014-11-14 9:09 ` Olivier MATZ
2014-11-17 6:52 ` Liu, Jijiang
2014-11-17 11:21 ` Olivier MATZ
2014-11-20 7:28 ` Liu, Jijiang
2014-11-20 16:36 ` Olivier MATZ
2014-11-21 5:40 ` Liu, Jijiang
2014-10-27 2:20 ` [dpdk-dev] [PATCH v8 00/10] Support VxLAN on Fortville Liu, Yong
2014-10-27 2:41 ` Zhang, Helin
2014-10-27 13:46 ` Thomas Monjalon
2014-10-27 14:34 ` Liu, Jijiang
2014-10-27 15:15 ` 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=2601191342CEEE43887BDE71AB977258213A3F5F@IRSMSX105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=jijiang.liu@intel.com \
--cc=olivier.matz@6wind.com \
--cc=yongwang@vmware.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).