netdev - Re: [PATCH] bnx2x: tx-switching module parameter

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: <1329416919.30697.2.camel@lb-tlvb-eilong.il.broadcom.com>
Date:	Thu, 16 Feb 2012 20:28:38 +0200
From:	"Eilon Greenstein" <eilong@...adcom.com>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
cc:	"Ariel Elior" <ariele@...adcom.com>, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH] bnx2x: tx-switching module parameter

On Thu, 2012-02-16 at 17:20 +0000, Ben Hutchings wrote:
> On Thu, 2012-02-16 at 16:05 +0200, Ariel Elior wrote:
> > In 57712 and 578xx the tx-switching module parameter allows the user to control
> > whether outgoing traffic can be loopbacked into the device in case there is a
> > relevant client for the data using the same device for rx.
> > A classic example where this is necessary is for virtualization purposes, where
> > one vm is transmitting data to another, while both use different pci functions of
> > the same port of the same nic.
> > 
> > In case there is a promiscuous client in the rx (which wants to receive all
> > data) or if the traffic is broadcast, traffic may be sent on both the loopback
> > channel and the physical wire.
> > 
> > The reason tx-switching is controlled by a module parameter is twofold:
> > 1. There is a certain performance penalty for tx-switching because:
> >    a. every packet must be compared against the receiver clients.
> >    b. duplicated traffic being loopbacked can consume a significant portion of
> >    the overall bandwidth, depending on the scenario.
> 
> So you really want the driver/firmware/hardware to know all the local
> addresses (as John Fastabend was proposing).

We need the HW to know the MAC addresses - L2 information only and each
PF is only configuring the addresses it owns (same addresses which are
used for Rx filtering anyway).

> > 2. Tx-switching doesn't make much sense as a per function parameter, but should
> > rather be controlled uniformly for the  entire device.
> [...]
> 
> What if there are multiple such cards in the same system, and this is
> only wanted for one of them?

Using this parameter is more likely in a physical device assignment in a
VM - having multiple devices that this rule apply to some but not all,
is possible - but less likely. It seem more convenient than using the
ethtool private flag and forcing the administrator to go over all PFs
(which sounds more common).



--
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