On Oct 23, 2015 9:30 AM, "Zhang, Helin" <helin.zhang at intel.com> 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" <helin.zhang at intel.com> 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 <wenzhuo.lu at intel.com> > > Acked-by: Helin Zhang <helin.zhang at intel.com> > >