netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 05:13:02 -0700	[thread overview]
Message-ID: <1402488782.2306.18.camel@jtkirshe-mobl> (raw)
In-Reply-To: <CAJZOPZJGZNhX7yPF6MvCjW+EYi-EGJgW1GhFa5CO=myAgJj-1A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

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,
than any packets with that mac address would be allowed out of the
interface.

If the VF attempts to send a packet with a mac address that has not been
sent to and accepted/configured by the PF than this would get blocked by
the anti-spoof detection.

The VF mac address must be configured by the PF in either case (set in
the host or set in the VM).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-06-11 12:13 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 [this message]
2014-06-11 12:43       ` Or Gerlitz
2014-06-11 14:37         ` Jeff Kirsher
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=1402488782.2306.18.camel@jtkirshe-mobl \
    --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).