diff for duplicates of <59AF69C657FD0841A61C55336867B5B07ED8B210@IRSMSX103.ger.corp.intel.com>
diff --git a/a/1.txt b/N1/1.txt
index cb455aa..21a2571 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,13 +1,13 @@
> -----Original Message-----
-> From: Jakub Kicinski [mailto:jakub.kicinski@netronome.com]
+> From: Jakub Kicinski [mailto:jakub.kicinski at netronome.com]
> Sent: Monday, July 1, 2019 10:20 PM
> To: Laatz, Kevin <kevin.laatz@intel.com>
-> Cc: Jonathan Lemon <jonathan.lemon@gmail.com>; netdev@vger.kernel.org;
-> ast@kernel.org; daniel@iogearbox.net; Topel, Bjorn
+> Cc: Jonathan Lemon <jonathan.lemon@gmail.com>; netdev at vger.kernel.org;
+> ast at kernel.org; daniel at iogearbox.net; Topel, Bjorn
> <bjorn.topel@intel.com>; Karlsson, Magnus <magnus.karlsson@intel.com>;
-> bpf@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Richardson, Bruce
+> bpf at vger.kernel.org; intel-wired-lan at lists.osuosl.org; Richardson, Bruce
> <bruce.richardson@intel.com>; Loftus, Ciara <ciara.loftus@intel.com>
> Subject: Re: [PATCH 00/11] XDP unaligned chunk placement support
>
@@ -15,7 +15,7 @@
> > On 28/06/2019 21:29, Jonathan Lemon wrote:
> > > On 28 Jun 2019, at 9:19, Laatz, Kevin wrote:
> > >> On 27/06/2019 22:25, Jakub Kicinski wrote:
-> > >>> I think that's very limiting. What is the challenge in providing
+> > >>> I think that's very limiting.? What is the challenge in providing
> > >>> aligned addresses, exactly?
> > >> The challenges are two-fold:
> > >> 1) it prevents using arbitrary buffer sizes, which will be an issue
@@ -23,19 +23,19 @@
> > >> 2) higher level user-space frameworks which may want to use AF_XDP,
> > >> such as DPDK, do not currently support having buffers with 'fixed'
> > >> alignment.
-> > >> The reason that DPDK uses arbitrary placement is that:
-> > >> - it would stop things working on certain NICs which need
+> > >> ??? The reason that DPDK uses arbitrary placement is that:
+> > >> ??? ??? - it would stop things working on certain NICs which need
> > >> the actual writable space specified in units of 1k - therefore we
> > >> need 2k
> > >> + metadata space.
-> > >> - we place padding between buffers to avoid constantly
+> > >> ??? ??? - we place padding between buffers to avoid constantly
> > >> hitting the same memory channels when accessing memory.
-> > >> - it allows the application to choose the actual buffer
+> > >> ??? ??? - it allows the application to choose the actual buffer
> > >> size it wants to use.
-> > >> We make use of the above to allow us to speed up processing
+> > >> ??? We make use of the above to allow us to speed up processing
> > >> significantly and also reduce the packet buffer memory size.
> > >>
-> > >> Not having arbitrary buffer alignment also means an AF_XDP
+> > >> ??? Not having arbitrary buffer alignment also means an AF_XDP
> > >> driver for DPDK cannot be a drop-in replacement for existing
> > >> drivers in those frameworks. Even with a new capability to allow an
> > >> arbitrary buffer alignment, existing apps will need to be modified
diff --git a/a/content_digest b/N1/content_digest
index d8e8d97..3aee4e0 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -26,29 +26,13 @@
"From\0Richardson, Bruce <bruce.richardson\@intel.com>\0"
]
[
- "Subject\0RE: [PATCH 00/11] XDP unaligned chunk placement support\0"
+ "Subject\0[Intel-wired-lan] [PATCH 00/11] XDP unaligned chunk placement support\0"
]
[
"Date\0Tue, 2 Jul 2019 09:27:38 +0000\0"
]
[
- "To\0Jakub Kicinski <jakub.kicinski\@netronome.com>",
- " Laatz",
- " Kevin <kevin.laatz\@intel.com>\0"
-]
-[
- "Cc\0Jonathan Lemon <jonathan.lemon\@gmail.com>",
- " netdev\@vger.kernel.org <netdev\@vger.kernel.org>",
- " ast\@kernel.org <ast\@kernel.org>",
- " daniel\@iogearbox.net <daniel\@iogearbox.net>",
- " Topel",
- " Bjorn <bjorn.topel\@intel.com>",
- " Karlsson",
- " Magnus <magnus.karlsson\@intel.com>",
- " bpf\@vger.kernel.org <bpf\@vger.kernel.org>",
- " intel-wired-lan\@lists.osuosl.org <intel-wired-lan\@lists.osuosl.org>",
- " Loftus",
- " Ciara <ciara.loftus\@intel.com>\0"
+ "To\0intel-wired-lan\@osuosl.org\0"
]
[
"\0000:1\0"
@@ -60,13 +44,13 @@
"\n",
"\n",
"> -----Original Message-----\n",
- "> From: Jakub Kicinski [mailto:jakub.kicinski\@netronome.com]\n",
+ "> From: Jakub Kicinski [mailto:jakub.kicinski at netronome.com]\n",
"> Sent: Monday, July 1, 2019 10:20 PM\n",
"> To: Laatz, Kevin <kevin.laatz\@intel.com>\n",
- "> Cc: Jonathan Lemon <jonathan.lemon\@gmail.com>; netdev\@vger.kernel.org;\n",
- "> ast\@kernel.org; daniel\@iogearbox.net; Topel, Bjorn\n",
+ "> Cc: Jonathan Lemon <jonathan.lemon\@gmail.com>; netdev at vger.kernel.org;\n",
+ "> ast at kernel.org; daniel at iogearbox.net; Topel, Bjorn\n",
"> <bjorn.topel\@intel.com>; Karlsson, Magnus <magnus.karlsson\@intel.com>;\n",
- "> bpf\@vger.kernel.org; intel-wired-lan\@lists.osuosl.org; Richardson, Bruce\n",
+ "> bpf at vger.kernel.org; intel-wired-lan at lists.osuosl.org; Richardson, Bruce\n",
"> <bruce.richardson\@intel.com>; Loftus, Ciara <ciara.loftus\@intel.com>\n",
"> Subject: Re: [PATCH 00/11] XDP unaligned chunk placement support\n",
"> \n",
@@ -74,7 +58,7 @@
"> > On 28/06/2019 21:29, Jonathan Lemon wrote:\n",
"> > > On 28 Jun 2019, at 9:19, Laatz, Kevin wrote:\n",
"> > >> On 27/06/2019 22:25, Jakub Kicinski wrote:\n",
- "> > >>> I think that's very limiting.\302\240 What is the challenge in providing\n",
+ "> > >>> I think that's very limiting.? What is the challenge in providing\n",
"> > >>> aligned addresses, exactly?\n",
"> > >> The challenges are two-fold:\n",
"> > >> 1) it prevents using arbitrary buffer sizes, which will be an issue\n",
@@ -82,19 +66,19 @@
"> > >> 2) higher level user-space frameworks which may want to use AF_XDP,\n",
"> > >> such as DPDK, do not currently support having buffers with 'fixed'\n",
"> > >> alignment.\n",
- "> > >> \302\240\302\240\302\240 The reason that DPDK uses arbitrary placement is that:\n",
- "> > >> \302\240\302\240\302\240 \302\240\302\240\302\240 - it would stop things working on certain NICs which need\n",
+ "> > >> ??? The reason that DPDK uses arbitrary placement is that:\n",
+ "> > >> ??? ??? - it would stop things working on certain NICs which need\n",
"> > >> the actual writable space specified in units of 1k - therefore we\n",
"> > >> need 2k\n",
"> > >> + metadata space.\n",
- "> > >> \302\240\302\240\302\240 \302\240\302\240\302\240 - we place padding between buffers to avoid constantly\n",
+ "> > >> ??? ??? - we place padding between buffers to avoid constantly\n",
"> > >> hitting the same memory channels when accessing memory.\n",
- "> > >> \302\240\302\240\302\240 \302\240\302\240\302\240 - it allows the application to choose the actual buffer\n",
+ "> > >> ??? ??? - it allows the application to choose the actual buffer\n",
"> > >> size it wants to use.\n",
- "> > >> \302\240\302\240\302\240 We make use of the above to allow us to speed up processing\n",
+ "> > >> ??? We make use of the above to allow us to speed up processing\n",
"> > >> significantly and also reduce the packet buffer memory size.\n",
"> > >>\n",
- "> > >> \302\240\302\240\302\240 Not having arbitrary buffer alignment also means an AF_XDP\n",
+ "> > >> ??? Not having arbitrary buffer alignment also means an AF_XDP\n",
"> > >> driver for DPDK cannot be a drop-in replacement for existing\n",
"> > >> drivers in those frameworks. Even with a new capability to allow an\n",
"> > >> arbitrary buffer alignment, existing apps will need to be modified\n",
@@ -139,4 +123,4 @@
"a buffer retains its base address the full way through the cycle of Rx and Tx."
]
-f54fa3a7475e0b09cb1202cd5e7bf74d5675faf657dc1dd70b42b4cd738665ef
+9921ceead25f2b5b44daffda0ded7931b9100e4aab7ad413f04b4e7b420813a0
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.