From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Or Gerlitz <or.gerlitz@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Mitch Williams <mitch.a.williams@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [net-next 06/13] i40e: implement anti-spoofing for VFs
Date: Wed, 11 Jun 2014 07:37:12 -0700 [thread overview]
Message-ID: <1402497432.2219.2.camel@jtkirshe-mobl.jf.intel.com> (raw)
In-Reply-To: <CAJZOPZLr-QYMfQ6homSvkDfUh+np3q5qbmRNLzBgxyWjk+LONQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Wed, 2014-06-11 at 15:43 +0300, Or Gerlitz wrote:
> On Wed, Jun 11, 2014 at 3:13 PM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > On Mon, 2014-06-09 at 22:49 +0300, Or Gerlitz wrote:
> >> On Mon, Jun 9, 2014 at 11:49 AM, Jeff Kirsher
> >> <jeffrey.t.kirsher@intel.com> wrote:
> >> > From: Mitch Williams <mitch.a.williams@intel.com>
> >> >
> >> > Our hardware supports VF antispoofing for both MAC addresses and VLANs.
> >> > Enable this feature by default for all VFs
> >>
> >> What do you expect the HW to do when spoof check is enabled (by
> >> default) but the admin didn't configure a MAC address for the VF
> >> through the PF? that is the VF is allowed to use what ever MAC they
> >> want to?
> >>
> >> > and implement the netdev op to control it from the command line.
> >
> > Here is the answer I got:
> > If the VF mac address is set within the VM and it is accepted by the PF,
>
> When the admin doesn't configure MAC address for the VM, what logic is
> applied by the PF to decide whether or not to accept a VF MAC set by the VM?
If the PF has not set the MAC address, it will check for a valid MAC
address that is neither broadcast or all zeros.
Look at the add_addr message handler i40e_vc_add_mac_addr_msg() or more
specifically i40e_check_vf_permission().
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-06-11 14:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 8:49 [net-next 00/13][pull request] Intel Wired LAN Driver Updates 2014-06-09 Jeff Kirsher
2014-06-09 8:49 ` [net-next 01/13] i40e: add checks for AQ error status bits Jeff Kirsher
2014-06-09 13:21 ` Sergei Shtylyov
2014-06-09 20:35 ` Jeff Kirsher
2014-06-09 21:02 ` Joe Perches
2014-06-09 21:10 ` Jeff Kirsher
2014-06-09 21:18 ` Joe Perches
2014-06-09 8:49 ` [net-next 02/13] i40evf: Fix function header Jeff Kirsher
2014-06-09 8:49 ` [net-next 03/13] i40e: allow for more VSIs Jeff Kirsher
2014-06-09 8:49 ` [net-next 04/13] i40e: remove unused variable and memory allocation Jeff Kirsher
2014-06-09 8:49 ` [net-next 05/13] i40e: don't complain about removing non-existent addresses Jeff Kirsher
2014-06-09 8:49 ` [net-next 06/13] i40e: implement anti-spoofing for VFs Jeff Kirsher
2014-06-09 19:49 ` Or Gerlitz
2014-06-11 12:13 ` Jeff Kirsher
2014-06-11 12:43 ` Or Gerlitz
2014-06-11 14:37 ` Jeff Kirsher [this message]
2014-06-09 8:49 ` [net-next 07/13] i40e: Changes to Interrupt distribution policy Jeff Kirsher
2014-06-09 8:49 ` [net-next 08/13] i40e: keep SR-IOV enabled in the case that RSS, VMDQ, FD_SB and DCB are disabled Jeff Kirsher
2014-06-09 8:49 ` [net-next 09/13] i40e/i40evf: add PPRS bit to error bits and fix bug in Rx checksum Jeff Kirsher
2014-06-09 8:49 ` [net-next 10/13] i40e: Do not fall back to one queue model if the only feature enabled is ATR Jeff Kirsher
2014-06-09 8:49 ` [net-next 11/13] i40e: Delete stale MAC filters after change Jeff Kirsher
2014-06-09 8:49 ` [net-next 12/13] i40e: Allow RSS table entry range and GPS to be any number, not necessarily power of 2 Jeff Kirsher
2014-06-09 8:49 ` [net-next 13/13] i40e/i40evf: bump version to 0.4.7 for i40e and 0.9.31 for i40evf Jeff Kirsher
2014-06-11 3:26 ` [net-next 00/13][pull request] Intel Wired LAN Driver Updates 2014-06-09 David Miller
2014-06-11 10:16 ` Jeff Kirsher
2014-06-11 10:42 ` Or Gerlitz
2014-06-11 12:05 ` Jeff Kirsher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402497432.2219.2.camel@jtkirshe-mobl.jf.intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=mitch.a.williams@intel.com \
--cc=netdev@vger.kernel.org \
--cc=or.gerlitz@gmail.com \
--cc=sassmann@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).