netdev - RE: [PATCH net-next] be2net: Learn and program mac to avoid packet replication in nPAR mode.

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] [day] [month] [year] [list]

Date:	Mon, 8 Sep 2014 16:17:50 +0000
From:	Venkat Duvvuru <VenkatKumar.Duvvuru@...lex.Com>
To:	"David Miller (davem@...emloft.net)" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] be2net: Learn and program mac to avoid packet
 replication in nPAR mode.



> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Saturday, September 06, 2014 6:05 AM
> To: Venkat Duvvuru
> Cc: netdev@...r.kernel.org
> Subject: Re: [PATCH net-next] be2net: Learn and program mac to avoid
> packet replication in nPAR mode.
> 
> From: Venkat Duvvuru <VenkatKumar.Duvvuru@...lex.com>
> Date: Thu, 4 Sep 2014 20:00:59 +0530
> 
> > In a multi-channel setup, when an interface (channel/partition) is used
> > by a bridge or ovs, it is placed in promiscuous mode and the MAC addresses
> > of the VMs attached to the bridge are not configured on the base
> interface.
> > As a result of that, when a packet arrives to the port with
> > virtual machine's mac address, the card cannot determine which ring to
> > send the packet to, so replicates the packet on all the PFs of that port,
> > hence resulting in wastage of PCI bandwidth and CPU cycles. Packet
> replication
> > is also considered security risk as it can cause packets to reach an undesired
> VM.
> >
> > This patch will help solve the problem by learning the mac address and
> > programming it in the adapter. This patch also unlearns the MAC, if the
> MAC is
> > moved out of the machine or if the MAC is inactive for more than 5
> minutes.
> >
> > Signed-off-by: Venkat Duvvuru <VenkatKumar.Duvvuru@...lex.com>
> 
> This is non-trivial overhead to add to the fast paths of your primary
> packet input and output paths.
> 
> I think you need to find a different solution to this problem.

A few points why I don't think this is non-trivial overhead
1. Mac learning happens only when there is a MAC miss and this is really a "once in a while" scenario.
2. There is no contention in the data path unless there is a MAC miss. 
3. Our experiments show that 
	a. There is almost no impact on the CPU because of mac learning.
	b. Throughput is not affected when there is no packet replication and this patch significantly improves the performance compared to throughput in a packet replication scenario.

Please let me know your thoughts.

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