lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f2db9d90909032135l26cfdba6n52329f6be75c16a5@mail.gmail.com>
Date:	Thu, 3 Sep 2009 21:35:17 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Or Gerlitz <ogerlitz@...taire.com>
Cc:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Fischer, Anna" <anna.fischer@...com>, netdev@...r.kernel.org
Subject: Re: L2 switching in igb

In regards to changing the VEPA mode I haven't given it much thought.
I don't think it would work out as an extension to the DCB netlink API
since the two technologies are mostly unrelated.  The suggestion I
received from Dave and Stephen was to consider an rtnl_link_ops for
configuring the VFs, but I still have issues trying to visualize how
that would work since I don't want the VFs spawning in the
host/hypervisor OS as network devices.

The replication enable allows multicast and broadcast packets to be
replicated across multiple VFs and the PF.  With it disabled the
packet will be forwarded to the first matching VF/PF pool and will not
be delivered to any others.  The Multicast Table Arrary (MTA) is
shared between all of the enabled VFs and the PF.  By setting the
accept packets matched in the MTA bit it essentially enables multicast
addresses for the VF/PF pool being enabled.  Without that bit being
set no multicast packets would be accepted.

Thanks,

Alex

On Thu, Sep 3, 2009 at 2:16 AM, Or Gerlitz<ogerlitz@...taire.com> wrote:
> Hi Alex, Jeff
>
> I see that igb_vmm_control enables L2 switch functionality & replication of
> multicast/broadcast packets across multiple pools (it calls both
> igb_vmdq_set_loopback/replication_pf with true).
>
> I wanted to check few related things with you:
>
> First, what you think would be the correct method for letting the user control
> if she wants the NIC to operate in VEPA mode (e.g forward VF/VF traffic to an
> outside bridge and let the later do a Uturn) or to handle VF/VF traffic
> internally? maybe it can be part or extension of the kernel DCB netlink API?
>
> second, does igb_vmdq_set_replication_pf cause multicast packets to be
> replicated to all VFs? I see that after invoking igb_vmm_control, there's
> a call to igb_set_vmolr which sets the "Accept packets matched in MTA"
> bit, so I wasn't sure what's is the final result, will the PF flood all
> multicast packets and the VF accept only those that have a match in the MTA?
>
> Or.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ