[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> > This patch will drop flow control frames from being transmitted from VSIs. > > With this patch in place a malicious VF cannot send flow control or PFC > > packets > > out on the wire. > > > > V2: > > Reword the comments. > > > > V3: > > Move the check of set_ethertype_anti_spoofing to the top of the function, to > > avoid occupying an ethertype_filter entity without using it. > > > > V4: > > Remove the useless braces and return. > > > > Signed-off-by: Wenzhuo Lu > Acked-by: Helin Zhang Applied, thanks
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> -Original Message- > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Friday, October 23, 2015 5:00 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > On 10/23/15 11:32, Zhang, Helin wrote: > > > >> -Original Message- > >> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > >> Sent: Friday, October 23, 2015 4:27 PM > >> To: Zhang, Helin > >> Cc: Lu, Wenzhuo; dev at dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >> from VFs > >> > >> > >> > >> On 10/23/15 10:14, Zhang, Helin wrote: > >>> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > >>> Sent: Friday, October 23, 2015 2:57 PM > >>> To: Zhang, Helin > >>> Cc: Lu, Wenzhuo; dev at dpdk.org > >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >>> from VFs > >>> > >>> > >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: > >>>> > >>>> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > >>>> Sent: Friday, October 23, 2015 2:24 PM > >>>> To: Zhang, Helin > >>>> Cc: Lu, Wenzhuo; dev at dpdk.org > >>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >>>> from VFs > >>>> > >>>> > >>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > >>>>> > >>>>>> -Original Message- > >>>>>> From: Lu, Wenzhuo > >>>>>> Sent: Friday, October 23, 2015 1:52 PM > >>>>>> To: dev at dpdk.org > >>>>>> Cc: Zhang, Helin; Lu, Wenzhuo > >>>>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > >>>>>> > >>>>>> This patch will drop flow control frames from being transmitted from > VSIs. > >>>>>> With this patch in place a malicious VF cannot send flow control > >>>>>> or PFC packets out on the wire. > >>>> The whole idea of this (and similar i40e patches sent before) is > >>>> really > >> confusing. > >>>> If u want to disable FC feature for VFs then go and disable the > >>>> feature. Why > >> keep (not malicious) user think that he/she has enabled the feature > >> while u silently block it? > >>>> Helin: I don't think disabling FC is equal to filtering out any > >>>> pause frames. How > >> about the software application constructs a pause frame and then > >> tries to send it out? > >>> But not disabling FC for the user and silently preventing it is > >>> bogus. First, the > >> conventional user should not be affected. I think this patch (and all > >> its clones) should be extended to, first, disable the FC Tx feature > >> for the relevant devices and only then adding any anti malicious filtering. > >>> Helin: Disabling FC will disable both PF and VF FC, I don't find out > >>> where can > >> disable VF FC only. Am I wrong? > >> > >> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used > >> for configuring FC. > >> I see that they are not set for either ixgbevf or i40evf, so here we > >> are all set for these. > > Helin: The behaviors rely on the hardware capability, but not the SW. > > I meant I don't think it can support disabling VF FC. Please correct me in > > case I > am wrong! > > I see. After a shallow sweep on the x540 and xl710 specs it seems that u r > right. > However I was talking about the SW interface only and since it is not enabled > for > the devices in question my whole objection is removed. > > thanks, > vlad Vlad, thank you very much! The best way for this issue is to do that in hardware, but now we need a fix/workaround. It is really good to have the discussion with you, and clarify a lot. I think it can also remove a lot of questions from others. Thank you! Regards, Helin > > > > > > >>>>>> V2: > >>>>>> Reword the comments. > >>>>>> > >>>>>> V3: > >>>>>> Move the check of set_ethertype_anti_spoofing to the top of the > >>>>>> function, > >> to > >>>>>> avoid occupying an ethertype_filter entity without using it. > >>>>>> > >>>>>> V4: > >>>>>> Remove the useless braces and return. > >>>>>> > >>>>>> Signed-off-by: Wenzhuo Lu > >>>>> Acked-by: Helin Zhang > >>>>>
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
This patch will drop flow control frames from being transmitted
from VSIs.
With this patch in place a malicious VF cannot send flow control
or PFC packets out on the wire.
V2:
Reword the comments.
V3:
Move the check of set_ethertype_anti_spoofing to the top of the function,
to avoid occupying an ethertype_filter entity without using it.
V4:
Remove the useless braces and return.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_pf.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index fd1c4ca..2ffbd1f 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -55,6 +55,7 @@
#define IXGBE_MAX_VFTA (128)
#define IXGBE_VF_MSG_SIZE_DEFAULT 1
#define IXGBE_VF_GET_QUEUE_MSG_SIZE 5
+#define IXGBE_ETHERTYPE_FLOW_CTRL 0x8808
static inline uint16_t
dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -166,6 +167,47 @@ void ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
*vfinfo = NULL;
}
+static void
+ixgbe_add_tx_flow_control_drop_filter(struct rte_eth_dev *eth_dev)
+{
+ struct ixgbe_hw *hw =
+ IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ struct ixgbe_filter_info *filter_info =
+ IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
+ uint16_t vf_num;
+ int i;
+
+ if (!hw->mac.ops.set_ethertype_anti_spoofing) {
+ RTE_LOG(INFO, PMD, "ether type anti-spoofing is not"
+ " supported.\n");
+ return;
+ }
+
+ /* occupy an entity of ether type filter */
+ for (i = 0; i < IXGBE_MAX_ETQF_FILTERS; i++) {
+ if (!(filter_info->ethertype_mask & (1 << i))) {
+ filter_info->ethertype_mask |= 1 << i;
+ filter_info->ethertype_filters[i] =
+ IXGBE_ETHERTYPE_FLOW_CTRL;
+ break;
+ }
+ }
+ if (i == IXGBE_MAX_ETQF_FILTERS) {
+ RTE_LOG(ERR, PMD, "Cannot find an unused ether type filter"
+ " entity for flow control.\n");
+ return;
+ }
+
+ IXGBE_WRITE_REG(hw, IXGBE_ETQF(i),
+ (IXGBE_ETQF_FILTER_EN |
+ IXGBE_ETQF_TX_ANTISPOOF |
+ IXGBE_ETHERTYPE_FLOW_CTRL));
+
+ vf_num = dev_num_vf(eth_dev);
+ for (i = 0; i < vf_num; i++)
+ hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
+}
+
int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
{
uint32_t vtctl, fcrth;
@@ -262,6 +304,8 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(i), fcrth);
}
+ ixgbe_add_tx_flow_control_drop_filter(eth_dev);
+
return 0;
}
--
1.9.3
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
On 10/23/15 11:32, Zhang, Helin wrote: > >> -Original Message- >> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] >> Sent: Friday, October 23, 2015 4:27 PM >> To: Zhang, Helin >> Cc: Lu, Wenzhuo; dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs >> >> >> >> On 10/23/15 10:14, Zhang, Helin wrote: >>> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] >>> Sent: Friday, October 23, 2015 2:57 PM >>> To: Zhang, Helin >>> Cc: Lu, Wenzhuo; dev at dpdk.org >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames >>> from VFs >>> >>> >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: >>>> >>>> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] >>>> Sent: Friday, October 23, 2015 2:24 PM >>>> To: Zhang, Helin >>>> Cc: Lu, Wenzhuo; dev at dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames >>>> from VFs >>>> >>>> >>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: >>>>> >>>>>> -Original Message- >>>>>> From: Lu, Wenzhuo >>>>>> Sent: Friday, October 23, 2015 1:52 PM >>>>>> To: dev at dpdk.org >>>>>> Cc: Zhang, Helin; Lu, Wenzhuo >>>>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs >>>>>> >>>>>> This patch will drop flow control frames from being transmitted from >>>>>> VSIs. >>>>>> With this patch in place a malicious VF cannot send flow control or >>>>>> PFC packets out on the wire. >>>> The whole idea of this (and similar i40e patches sent before) is really >> confusing. >>>> If u want to disable FC feature for VFs then go and disable the feature. >>>> Why >> keep (not malicious) user think that he/she has enabled the feature while u >> silently block it? >>>> Helin: I don't think disabling FC is equal to filtering out any pause >>>> frames. How >> about the software application constructs a pause frame and then tries to >> send it >> out? >>> But not disabling FC for the user and silently preventing it is bogus. >>> First, the >> conventional user should not be affected. I think this patch (and all its >> clones) >> should be extended to, first, disable the FC Tx feature for the relevant >> devices >> and only then adding any anti malicious filtering. >>> Helin: Disabling FC will disable both PF and VF FC, I don't find out where >>> can >> disable VF FC only. Am I wrong? >> >> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for >> configuring FC. >> I see that they are not set for either ixgbevf or i40evf, so here we are all >> set for >> these. > Helin: The behaviors rely on the hardware capability, but not the SW. > I meant I don't think it can support disabling VF FC. Please correct me in > case I am wrong! I see. After a shallow sweep on the x540 and xl710 specs it seems that u r right. However I was talking about the SW interface only and since it is not enabled for the devices in question my whole objection is removed. thanks, vlad > > >>>>>> V2: >>>>>> Reword the comments. >>>>>> >>>>>> V3: >>>>>> Move the check of set_ethertype_anti_spoofing to the top of the function, >> to >>>>>> avoid occupying an ethertype_filter entity without using it. >>>>>> >>>>>> V4: >>>>>> Remove the useless braces and return. >>>>>> >>>>>> Signed-off-by: Wenzhuo Lu >>>>> Acked-by: Helin Zhang >>>>>
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
On 10/23/15 10:14, Zhang, Helin wrote: > > From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Friday, October 23, 2015 2:57 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: >> >> >> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] >> Sent: Friday, October 23, 2015 2:24 PM >> To: Zhang, Helin >> Cc: Lu, Wenzhuo; dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs >> >> >> On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: >>> >>> >>>> -Original Message- >>>> From: Lu, Wenzhuo >>>> Sent: Friday, October 23, 2015 1:52 PM >>>> To: dev at dpdk.org >>>> Cc: Zhang, Helin; Lu, Wenzhuo >>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs >>>> >>>> This patch will drop flow control frames from being transmitted from VSIs. >>>> With this patch in place a malicious VF cannot send flow control or PFC >>>> packets >>>> out on the wire. >> The whole idea of this (and similar i40e patches sent before) is really >> confusing. >> If u want to disable FC feature for VFs then go and disable the feature. Why >> keep (not malicious) user think that he/she has enabled the feature while u >> silently block it? >> >> Helin: I don't think disabling FC is equal to filtering out any pause >> frames. How about the software application constructs a pause frame and then >> tries to send it out? > But not disabling FC for the user and silently preventing it is bogus. First, > the conventional user should not be affected. I think this patch (and all its > clones) should be extended to, first, disable the FC Tx feature for the > relevant devices and only then adding any anti malicious filtering. > > Helin: Disabling FC will disable both PF and VF FC, I don't find out where > can disable VF FC only. Am I wrong? There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for configuring FC. I see that they are not set for either ixgbevf or i40evf, so here we are all set for these. > >>>> V2: >>>> Reword the comments. >>>> >>>> V3: >>>> Move the check of set_ethertype_anti_spoofing to the top of the function, >>>> to >>>> avoid occupying an ethertype_filter entity without using it. >>>> >>>> V4: >>>> Remove the useless braces and return. >>>> >>>> Signed-off-by: Wenzhuo Lu >>> Acked-by: Helin Zhang >>>
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: > > > > From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Friday, October 23, 2015 2:24 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > > > > > > > > > -Original Message- > > > From: Lu, Wenzhuo > > > Sent: Friday, October 23, 2015 1:52 PM > > > To: dev at dpdk.org > > > Cc: Zhang, Helin; Lu, Wenzhuo > > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > > > This patch will drop flow control frames from being transmitted from VSIs. > > > With this patch in place a malicious VF cannot send flow control or PFC packets > > > out on the wire. > The whole idea of this (and similar i40e patches sent before) is really confusing. > If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it? > > Helin: I don't think disabling FC is equal to filtering out any pause frames. How about the software application constructs a pause frame and then tries to send it out? But not disabling FC for the user and silently preventing it is bogus. First, the conventional user should not be affected. I think this patch (and all its clones) should be extended to, first, disable the FC Tx feature for the relevant devices and only then adding any anti malicious filtering. > > > > > > > V2: > > > Reword the comments. > > > > > > V3: > > > Move the check of set_ethertype_anti_spoofing to the top of the function, to > > > avoid occupying an ethertype_filter entity without using it. > > > > > > V4: > > > Remove the useless braces and return. > > > > > > Signed-off-by: Wenzhuo Lu > > Acked-by: Helin Zhang > >
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > > > > > -Original Message- > > From: Lu, Wenzhuo > > Sent: Friday, October 23, 2015 1:52 PM > > To: dev at dpdk.org > > Cc: Zhang, Helin; Lu, Wenzhuo > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > This patch will drop flow control frames from being transmitted from VSIs. > > With this patch in place a malicious VF cannot send flow control or PFC packets > > out on the wire. The whole idea of this (and similar i40e patches sent before) is really confusing. If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it? > > > > V2: > > Reword the comments. > > > > V3: > > Move the check of set_ethertype_anti_spoofing to the top of the function, to > > avoid occupying an ethertype_filter entity without using it. > > > > V4: > > Remove the useless braces and return. > > > > Signed-off-by: Wenzhuo Lu > Acked-by: Helin Zhang >
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> -Original Message- > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Friday, October 23, 2015 4:27 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > On 10/23/15 10:14, Zhang, Helin wrote: > > > > From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > > Sent: Friday, October 23, 2015 2:57 PM > > To: Zhang, Helin > > Cc: Lu, Wenzhuo; dev at dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > > from VFs > > > > > > On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: > >> > >> > >> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > >> Sent: Friday, October 23, 2015 2:24 PM > >> To: Zhang, Helin > >> Cc: Lu, Wenzhuo; dev at dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >> from VFs > >> > >> > >> On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > >>> > >>> > >>>> -Original Message- > >>>> From: Lu, Wenzhuo > >>>> Sent: Friday, October 23, 2015 1:52 PM > >>>> To: dev at dpdk.org > >>>> Cc: Zhang, Helin; Lu, Wenzhuo > >>>> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > >>>> > >>>> This patch will drop flow control frames from being transmitted from > >>>> VSIs. > >>>> With this patch in place a malicious VF cannot send flow control or > >>>> PFC packets out on the wire. > >> The whole idea of this (and similar i40e patches sent before) is really > confusing. > >> If u want to disable FC feature for VFs then go and disable the feature. > >> Why > keep (not malicious) user think that he/she has enabled the feature while u > silently block it? > >> > >> Helin: I don't think disabling FC is equal to filtering out any pause > >> frames. How > about the software application constructs a pause frame and then tries to > send it > out? > > But not disabling FC for the user and silently preventing it is bogus. > > First, the > conventional user should not be affected. I think this patch (and all its > clones) > should be extended to, first, disable the FC Tx feature for the relevant > devices > and only then adding any anti malicious filtering. > > > > Helin: Disabling FC will disable both PF and VF FC, I don't find out where > > can > disable VF FC only. Am I wrong? > > There are flow_ctrl_get/set callbacks in eth_dev_ops which are used for > configuring FC. > I see that they are not set for either ixgbevf or i40evf, so here we are all > set for > these. Helin: The behaviors rely on the hardware capability, but not the SW. I meant I don't think it can support disabling VF FC. Please correct me in case I am wrong! > > > > >>>> V2: > >>>> Reword the comments. > >>>> > >>>> V3: > >>>> Move the check of set_ethertype_anti_spoofing to the top of the function, > to > >>>> avoid occupying an ethertype_filter entity without using it. > >>>> > >>>> V4: > >>>> Remove the useless braces and return. > >>>> > >>>> Signed-off-by: Wenzhuo Lu > >>> Acked-by: Helin Zhang > >>>
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
From: Vladislav Zolotarov [mailto:vl...@cloudius-systems.com] Sent: Friday, October 23, 2015 2:57 PM To: Zhang, Helin Cc: Lu, Wenzhuo; dev at dpdk.org Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs On Oct 23, 2015 9:30 AM, "Zhang, Helin" wrote: > > > > From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Friday, October 23, 2015 2:24 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > > > > > > > > > -Original Message- > > > From: Lu, Wenzhuo > > > Sent: Friday, October 23, 2015 1:52 PM > > > To: dev at dpdk.org > > > Cc: Zhang, Helin; Lu, Wenzhuo > > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > > > This patch will drop flow control frames from being transmitted from VSIs. > > > With this patch in place a malicious VF cannot send flow control or PFC > > > packets > > > out on the wire. > The whole idea of this (and similar i40e patches sent before) is really > confusing. > If u want to disable FC feature for VFs then go and disable the feature. Why > keep (not malicious) user think that he/she has enabled the feature while u > silently block it? > > Helin: I don't think disabling FC is equal to filtering out any pause frames. > How about the software application constructs a pause frame and then tries to > send it out? But not disabling FC for the user and silently preventing it is bogus. First, the conventional user should not be affected. I think this patch (and all its clones) should be extended to, first, disable the FC Tx feature for the relevant devices and only then adding any anti malicious filtering. Helin: Disabling FC will disable both PF and VF FC, I don't find out where can disable VF FC only. Am I wrong? > > > > > > > V2: > > > Reword the comments. > > > > > > V3: > > > Move the check of set_ethertype_anti_spoofing to the top of the function, > > > to > > > avoid occupying an ethertype_filter entity without using it. > > > > > > V4: > > > Remove the useless braces and return. > > > > > > Signed-off-by: Wenzhuo Lu > > Acked-by: Helin Zhang > >
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
From: Vladislav Zolotarov [mailto:vl...@cloudius-systems.com] Sent: Friday, October 23, 2015 2:24 PM To: Zhang, Helin Cc: Lu, Wenzhuo; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs On Oct 23, 2015 9:02 AM, "Zhang, Helin" wrote: > > > > > -Original Message- > > From: Lu, Wenzhuo > > Sent: Friday, October 23, 2015 1:52 PM > > To: dev at dpdk.org > > Cc: Zhang, Helin; Lu, Wenzhuo > > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > > > > This patch will drop flow control frames from being transmitted from VSIs. > > With this patch in place a malicious VF cannot send flow control or PFC > > packets > > out on the wire. The whole idea of this (and similar i40e patches sent before) is really confusing. If u want to disable FC feature for VFs then go and disable the feature. Why keep (not malicious) user think that he/she has enabled the feature while u silently block it? Helin: I don't think disabling FC is equal to filtering out any pause frames. How about the software application constructs a pause frame and then tries to send it out? > > > > V2: > > Reword the comments. > > > > V3: > > Move the check of set_ethertype_anti_spoofing to the top of the function, to > > avoid occupying an ethertype_filter entity without using it. > > > > V4: > > Remove the useless braces and return. > > > > Signed-off-by: Wenzhuo Lu > Acked-by: Helin Zhang >
[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> -Original Message- > From: Lu, Wenzhuo > Sent: Friday, October 23, 2015 1:52 PM > To: dev at dpdk.org > Cc: Zhang, Helin; Lu, Wenzhuo > Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs > > This patch will drop flow control frames from being transmitted from VSIs. > With this patch in place a malicious VF cannot send flow control or PFC > packets > out on the wire. > > V2: > Reword the comments. > > V3: > Move the check of set_ethertype_anti_spoofing to the top of the function, to > avoid occupying an ethertype_filter entity without using it. > > V4: > Remove the useless braces and return. > > Signed-off-by: Wenzhuo Lu Acked-by: Helin Zhang
