* [dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode @ 2015-10-10 2:56 Wenzhuo Lu 2015-10-22 7:34 ` [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs Wenzhuo Lu 2015-10-23 5:52 ` [dpdk-dev] [PATCH v4] " Wenzhuo Lu 0 siblings, 2 replies; 15+ messages in thread From: Wenzhuo Lu @ 2015-10-10 2:56 UTC (permalink / raw) To: dev; +Cc: yulong.pei In SR-IOV mode a VF sending LFC or PFC would throttle the entire port. The workaround is to add a filter to drop pause frames from VFs from sending pause frames. Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com> --- drivers/net/ixgbe/ixgbe_pf.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index fd1c4ca..b33f4e9 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,46 @@ 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; + + /* 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; + } + + if (hw->mac.ops.set_ethertype_anti_spoofing) { + 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); + } + } + + return; +} + int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev) { uint32_t vtctl, fcrth; @@ -262,6 +303,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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs 2015-10-10 2:56 [dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode Wenzhuo Lu @ 2015-10-22 7:34 ` Wenzhuo Lu 2015-10-23 2:49 ` Zhang, Helin 2015-10-23 5:52 ` [dpdk-dev] [PATCH v4] " Wenzhuo Lu 1 sibling, 1 reply; 15+ messages in thread From: Wenzhuo Lu @ 2015-10-22 7:34 UTC (permalink / raw) To: dev 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. Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com> --- drivers/net/ixgbe/ixgbe_pf.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index fd1c4ca..b33f4e9 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,46 @@ 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; + + /* 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; + } + + if (hw->mac.ops.set_ethertype_anti_spoofing) { + 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); + } + } + + return; +} + int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev) { uint32_t vtctl, fcrth; @@ -262,6 +303,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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs 2015-10-22 7:34 ` [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs Wenzhuo Lu @ 2015-10-23 2:49 ` Zhang, Helin 2015-10-23 3:26 ` Lu, Wenzhuo 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Helin @ 2015-10-23 2:49 UTC (permalink / raw) To: Lu, Wenzhuo, dev > -----Original Message----- > From: Lu, Wenzhuo > Sent: Thursday, October 22, 2015 3:34 PM > To: dev@dpdk.org > Cc: Zhang, Helin; Lu, Wenzhuo > Subject: [PATCH v2] 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. > > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com> > --- > drivers/net/ixgbe/ixgbe_pf.c | 43 > +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index > fd1c4ca..b33f4e9 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,46 @@ 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; > + > + /* 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; > + } > + > + if (hw->mac.ops.set_ethertype_anti_spoofing) { > + 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); > + } > + } ixgbe_set_ethertype_anti_spoofing() is exposed by ixgbe_api.h, and can be used directly. I think we need a return value for above function, and then the caller can check it. If it fails, does it need to return out, or just skip the failure? In addition, is this operation only for x550, right? If yes, it may need a check above. Regards, Helin > + > + return; > +} > + > int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev) { > uint32_t vtctl, fcrth; > @@ -262,6 +303,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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs 2015-10-23 2:49 ` Zhang, Helin @ 2015-10-23 3:26 ` Lu, Wenzhuo 0 siblings, 0 replies; 15+ messages in thread From: Lu, Wenzhuo @ 2015-10-23 3:26 UTC (permalink / raw) To: Zhang, Helin, dev Hi Helin, > -----Original Message----- > From: Zhang, Helin > Sent: Friday, October 23, 2015 10:49 AM > To: Lu, Wenzhuo; dev@dpdk.org > Subject: RE: [PATCH v2] ixgbe: Drop flow control frames from VFs > > > > > -----Original Message----- > > From: Lu, Wenzhuo > > Sent: Thursday, October 22, 2015 3:34 PM > > To: dev@dpdk.org > > Cc: Zhang, Helin; Lu, Wenzhuo > > Subject: [PATCH v2] 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. > > > > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com> > > --- > > drivers/net/ixgbe/ixgbe_pf.c | 43 > > +++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/drivers/net/ixgbe/ixgbe_pf.c > > b/drivers/net/ixgbe/ixgbe_pf.c index > > fd1c4ca..b33f4e9 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,46 @@ 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; > > + > > + /* 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; > > + } > > + > > + if (hw->mac.ops.set_ethertype_anti_spoofing) { > > + 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); > > + } > > + } > ixgbe_set_ethertype_anti_spoofing() is exposed by ixgbe_api.h, and can be > used directly. > I think we need a return value for above function, and then the caller can > check it. > If it fails, does it need to return out, or just skip the failure? For it's an additional check, I don't want to let it break the normal process. If there's a failure (suppose not, because it's executed during init, there should be enough ether type entities.), only output error log. > In addition, is this operation only for x550, right? If yes, it may need a check > above. It's depends on if this NIC supports this function " hw->mac.ops.set_ethertype_anti_spoofing", If some new ixgbe NICs can support it in future, we need not change the code. But seems I should check it first to avoid occupy a ethertype_filter entity without using it. I'll send a V2. > > Regards, > Helin > > > + > > + return; > > +} > > + > > int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev) { > > uint32_t vtctl, fcrth; > > @@ -262,6 +303,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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-10 2:56 [dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode Wenzhuo Lu 2015-10-22 7:34 ` [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs Wenzhuo Lu @ 2015-10-23 5:52 ` Wenzhuo Lu 2015-10-23 6:02 ` Zhang, Helin 1 sibling, 1 reply; 15+ messages in thread From: Wenzhuo Lu @ 2015-10-23 5:52 UTC (permalink / raw) To: dev 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 <wenzhuo.lu@intel.com> --- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 5:52 ` [dpdk-dev] [PATCH v4] " Wenzhuo Lu @ 2015-10-23 6:02 ` Zhang, Helin 2015-10-23 6:24 ` Vladislav Zolotarov 2015-10-28 16:42 ` Thomas Monjalon 0 siblings, 2 replies; 15+ messages in thread From: Zhang, Helin @ 2015-10-23 6:02 UTC (permalink / raw) To: Lu, Wenzhuo; +Cc: dev > -----Original Message----- > From: Lu, Wenzhuo > Sent: Friday, October 23, 2015 1:52 PM > To: dev@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 <wenzhuo.lu@intel.com> Acked-by: Helin Zhang <helin.zhang@intel.com> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 6:02 ` Zhang, Helin @ 2015-10-23 6:24 ` Vladislav Zolotarov 2015-10-23 6:30 ` Zhang, Helin 2015-10-28 16:42 ` Thomas Monjalon 1 sibling, 1 reply; 15+ messages in thread From: Vladislav Zolotarov @ 2015-10-23 6:24 UTC (permalink / raw) To: Helin Zhang; +Cc: dev On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > > -----Original Message----- > > From: Lu, Wenzhuo > > Sent: Friday, October 23, 2015 1:52 PM > > To: dev@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 <wenzhuo.lu@intel.com> > Acked-by: Helin Zhang <helin.zhang@intel.com> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 6:24 ` Vladislav Zolotarov @ 2015-10-23 6:30 ` Zhang, Helin 2015-10-23 6:57 ` Vladislav Zolotarov 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Helin @ 2015-10-23 6:30 UTC (permalink / raw) To: Vladislav Zolotarov; +Cc: dev From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] Sent: Friday, October 23, 2015 2:24 PM To: Zhang, Helin Cc: Lu, Wenzhuo; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > > -----Original Message----- > > From: Lu, Wenzhuo > > Sent: Friday, October 23, 2015 1:52 PM > > To: dev@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 <wenzhuo.lu@intel.com> > Acked-by: Helin Zhang <helin.zhang@intel.com> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 6:30 ` Zhang, Helin @ 2015-10-23 6:57 ` Vladislav Zolotarov 2015-10-23 7:14 ` Zhang, Helin 0 siblings, 1 reply; 15+ messages in thread From: Vladislav Zolotarov @ 2015-10-23 6:57 UTC (permalink / raw) To: Helin Zhang; +Cc: dev On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Friday, October 23, 2015 2:24 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Lu, Wenzhuo > > > Sent: Friday, October 23, 2015 1:52 PM > > > To: dev@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 <wenzhuo.lu@intel.com> > > Acked-by: Helin Zhang <helin.zhang@intel.com> > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 6:57 ` Vladislav Zolotarov @ 2015-10-23 7:14 ` Zhang, Helin 2015-10-23 8:27 ` Vlad Zolotarov 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Helin @ 2015-10-23 7:14 UTC (permalink / raw) To: Vladislav Zolotarov; +Cc: dev From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] Sent: Friday, October 23, 2015 2:57 PM To: Zhang, Helin Cc: Lu, Wenzhuo; dev@dpdk.org Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Friday, October 23, 2015 2:24 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Lu, Wenzhuo > > > Sent: Friday, October 23, 2015 1:52 PM > > > To: dev@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 <wenzhuo.lu@intel.com> > > Acked-by: Helin Zhang <helin.zhang@intel.com> > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 7:14 ` Zhang, Helin @ 2015-10-23 8:27 ` Vlad Zolotarov 2015-10-23 8:32 ` Zhang, Helin 0 siblings, 1 reply; 15+ messages in thread From: Vlad Zolotarov @ 2015-10-23 8:27 UTC (permalink / raw) To: Zhang, Helin; +Cc: dev On 10/23/15 10:14, Zhang, Helin wrote: > > From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Friday, October 23, 2015 2:57 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs > > > On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: >> >> >> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] >> Sent: Friday, October 23, 2015 2:24 PM >> To: Zhang, Helin >> Cc: Lu, Wenzhuo; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs >> >> >> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: >>> >>> >>>> -----Original Message----- >>>> From: Lu, Wenzhuo >>>> Sent: Friday, October 23, 2015 1:52 PM >>>> To: dev@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 <wenzhuo.lu@intel.com> >>> Acked-by: Helin Zhang <helin.zhang@intel.com> >>> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 8:27 ` Vlad Zolotarov @ 2015-10-23 8:32 ` Zhang, Helin 2015-10-23 9:00 ` Vlad Zolotarov 0 siblings, 1 reply; 15+ messages in thread From: Zhang, Helin @ 2015-10-23 8:32 UTC (permalink / raw) To: Vlad Zolotarov; +Cc: dev > -----Original Message----- > From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Friday, October 23, 2015 4:27 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev@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@cloudius-systems.com] > > Sent: Friday, October 23, 2015 2:57 PM > > To: Zhang, Helin > > Cc: Lu, Wenzhuo; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > > from VFs > > > > > > On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > >> > >> > >> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] > >> Sent: Friday, October 23, 2015 2:24 PM > >> To: Zhang, Helin > >> Cc: Lu, Wenzhuo; dev@dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >> from VFs > >> > >> > >> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lu, Wenzhuo > >>>> Sent: Friday, October 23, 2015 1:52 PM > >>>> To: dev@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 <wenzhuo.lu@intel.com> > >>> Acked-by: Helin Zhang <helin.zhang@intel.com> > >>> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 8:32 ` Zhang, Helin @ 2015-10-23 9:00 ` Vlad Zolotarov 2015-10-26 0:47 ` Zhang, Helin 0 siblings, 1 reply; 15+ messages in thread From: Vlad Zolotarov @ 2015-10-23 9:00 UTC (permalink / raw) To: Zhang, Helin; +Cc: dev On 10/23/15 11:32, Zhang, Helin wrote: > >> -----Original Message----- >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >> Sent: Friday, October 23, 2015 4:27 PM >> To: Zhang, Helin >> Cc: Lu, Wenzhuo; dev@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@cloudius-systems.com] >>> Sent: Friday, October 23, 2015 2:57 PM >>> To: Zhang, Helin >>> Cc: Lu, Wenzhuo; dev@dpdk.org >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames >>> from VFs >>> >>> >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: >>>> >>>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] >>>> Sent: Friday, October 23, 2015 2:24 PM >>>> To: Zhang, Helin >>>> Cc: Lu, Wenzhuo; dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames >>>> from VFs >>>> >>>> >>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: Lu, Wenzhuo >>>>>> Sent: Friday, October 23, 2015 1:52 PM >>>>>> To: dev@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 <wenzhuo.lu@intel.com> >>>>> Acked-by: Helin Zhang <helin.zhang@intel.com> >>>>> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 9:00 ` Vlad Zolotarov @ 2015-10-26 0:47 ` Zhang, Helin 0 siblings, 0 replies; 15+ messages in thread From: Zhang, Helin @ 2015-10-26 0:47 UTC (permalink / raw) To: Vlad Zolotarov; +Cc: dev > -----Original Message----- > From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Friday, October 23, 2015 5:00 PM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev@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@cloudius-systems.com] > >> Sent: Friday, October 23, 2015 4:27 PM > >> To: Zhang, Helin > >> Cc: Lu, Wenzhuo; dev@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@cloudius-systems.com] > >>> Sent: Friday, October 23, 2015 2:57 PM > >>> To: Zhang, Helin > >>> Cc: Lu, Wenzhuo; dev@dpdk.org > >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >>> from VFs > >>> > >>> > >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > >>>> > >>>> From: Vladislav Zolotarov [mailto:vladz@cloudius-systems.com] > >>>> Sent: Friday, October 23, 2015 2:24 PM > >>>> To: Zhang, Helin > >>>> Cc: Lu, Wenzhuo; dev@dpdk.org > >>>> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames > >>>> from VFs > >>>> > >>>> > >>>> On Oct 23, 2015 9:02 AM, "Zhang, Helin" <helin.zhang@intel.com> wrote: > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lu, Wenzhuo > >>>>>> Sent: Friday, October 23, 2015 1:52 PM > >>>>>> To: dev@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 <wenzhuo.lu@intel.com> > >>>>> Acked-by: Helin Zhang <helin.zhang@intel.com> > >>>>> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs 2015-10-23 6:02 ` Zhang, Helin 2015-10-23 6:24 ` Vladislav Zolotarov @ 2015-10-28 16:42 ` Thomas Monjalon 1 sibling, 0 replies; 15+ messages in thread From: Thomas Monjalon @ 2015-10-28 16:42 UTC (permalink / raw) To: Lu, Wenzhuo; +Cc: dev > > 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 <wenzhuo.lu@intel.com> > Acked-by: Helin Zhang <helin.zhang@intel.com> Applied, thanks ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-10-28 16:43 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-10 2:56 [dpdk-dev] [PATCH] ixgbe: workaround for Security issue in SR-IOV mode Wenzhuo Lu 2015-10-22 7:34 ` [dpdk-dev] [PATCH v2] ixgbe: Drop flow control frames from VFs Wenzhuo Lu 2015-10-23 2:49 ` Zhang, Helin 2015-10-23 3:26 ` Lu, Wenzhuo 2015-10-23 5:52 ` [dpdk-dev] [PATCH v4] " Wenzhuo Lu 2015-10-23 6:02 ` Zhang, Helin 2015-10-23 6:24 ` Vladislav Zolotarov 2015-10-23 6:30 ` Zhang, Helin 2015-10-23 6:57 ` Vladislav Zolotarov 2015-10-23 7:14 ` Zhang, Helin 2015-10-23 8:27 ` Vlad Zolotarov 2015-10-23 8:32 ` Zhang, Helin 2015-10-23 9:00 ` Vlad Zolotarov 2015-10-26 0:47 ` Zhang, Helin 2015-10-28 16:42 ` Thomas Monjalon
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).