diff for duplicates of <F6FB0E698C9B3143BDF729DF22286646912AD3E7@ORSMSX110.amr.corp.intel.com>
diff --git a/a/1.txt b/N1/1.txt
index 1980873..56dcb2d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,7 +4,7 @@
From: Edward Cree [mailto:ecree@solarflare.com]
Sent: Friday, February 20, 2015 5:52 AM
To: Hiroshi Shimamoto
-Cc: Skidmore, Donald C; vyasevic@redhat.com; Kirsher, Jeffrey T; Alexander Duyck; Bjørn Mork; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy Jong; linux-kernel@vger.kernel.org; David Laight; Hayato Momma
+Cc: Skidmore, Donald C; vyasevic@redhat.com; Kirsher, Jeffrey T; Alexander Duyck; Bjørn Mork; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy Jong; linux-kernel@vger.kernel.org; David Laight; Hayato Momma
Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
On 20/02/15 01:00, Hiroshi Shimamoto wrote:
@@ -26,6 +26,4 @@ If a vender specific interface is objectionable maybe a simpler and more generic
As to why someone may want to block a VF from entering multicast promiscuous it has more to do with performance that security. The issue is this could have a very noticeably effect on the overall system. If any other VFs (or the PF) are receiving MC packets these will have to be replicated which will be a performance hit. When we use the MC hash this is limited vs. when anyone is in MC promiscuous every MC packet used by another pool would be replicated. . If too many VF's were in this mode you run the risk for flooding the PCIe interface. I could imagine in some environments (i.e. public clouds) where you don't trust what is running in your VM you might what to block this from happening.
-- Don Skidmore <donald.c.skidmore@intel.com>
-
-ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
\ No newline at end of file
+- Don Skidmore <donald.c.skidmore@intel.com>
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 5dbb324..fb4b77e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -44,7 +44,7 @@
"From: Edward Cree [mailto:ecree\@solarflare.com] \n",
"Sent: Friday, February 20, 2015 5:52 AM\n",
"To: Hiroshi Shimamoto\n",
- "Cc: Skidmore, Donald C; vyasevic\@redhat.com; Kirsher, Jeffrey T; Alexander Duyck; Bj\303\203\302\270rn Mork; e1000-devel\@lists.sourceforge.net; netdev\@vger.kernel.org; Choi, Sy Jong; linux-kernel\@vger.kernel.org; David Laight; Hayato Momma\n",
+ "Cc: Skidmore, Donald C; vyasevic\@redhat.com; Kirsher, Jeffrey T; Alexander Duyck; Bj\303\270rn Mork; e1000-devel\@lists.sourceforge.net; netdev\@vger.kernel.org; Choi, Sy Jong; linux-kernel\@vger.kernel.org; David Laight; Hayato Momma\n",
"Subject: Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control\n",
"\n",
"On 20/02/15 01:00, Hiroshi Shimamoto wrote:\n",
@@ -66,9 +66,7 @@
"\n",
"As to why someone may want to block a VF from entering multicast promiscuous it has more to do with performance that security. The issue is this could have a very noticeably effect on the overall system. If any other VFs (or the PF) are receiving MC packets these will have to be replicated which will be a performance hit. When we use the MC hash this is limited vs. when anyone is in MC promiscuous every MC packet used by another pool would be replicated. . If too many VF's were in this mode you run the risk for flooding the PCIe interface. I could imagine in some environments (i.e. public clouds) where you don't trust what is running in your VM you might what to block this from happening.\n",
"\n",
- "- Don Skidmore <donald.c.skidmore\@intel.com>\n",
- "\n",
- "\303\277\303\264\303\250\302\272{.n\303\207+\302\211\302\267\302\237\302\256\302\211\302\255\302\206+%\302\212\303\213\303\277\302\261\303\251\303\235\302\266\27\302\245\302\212w\303\277\302\272{.n\303\207+\302\211\302\267\302\245\302\212{\302\261\303\276G\302\253\302\235\303\251\303\277\302\212{ay\302\272\35\303\212\302\207\303\232\302\231\303\253,j\a\302\255\302\242f\302\243\302\242\302\267h\302\232\302\217\303\257\302\201\303\252\303\277\302\221\303\252\303\247z_\303\250\302\256\3(\302\255\303\251\302\232\302\216\302\212\303\235\302\242j\"\302\235\303\272\32\302\266\em\302\247\303\277\303\277\302\276\a\302\253\303\276G\302\253\302\235\303\251\303\277\302\242\302\270?\302\231\302\250\303\250\302\255\303\232&\302\243\303\270\302\247~\302\217\303\241\302\266iO\302\225\303\246\302\254z\302\267\302\232v\303\230^\24\4\32\302\266\em\302\247\303\277\303\277\303\203\f\303\277\302\266\303\254\303\277\302\242\302\270?\302\226I\302\245"
+ "- Don Skidmore <donald.c.skidmore\@intel.com>"
]
-acf301ea02620e3cd287c86f8c27641a07150d7126796907bf7f58d32aa5a486
+0f9d2ba58b4ff4f293dc9841431a0b207708215ff1aded208e200dfd7d9f5aec
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.