netdev - Re: [PATCH net] openvswitch: compute needed headroom for internal vports

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]

Date:	Fri, 8 Jan 2016 18:44:04 -0800
From:	pravin shelar <pshelar@....org>
To:	Jesse Gross <jesse@...nel.org>
Cc:	Paolo Abeni <pabeni@...hat.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Pravin Shelar <pshelar@...ira.com>,
	"David S. Miller" <davem@...emloft.net>,
	Flavio Leitner <fbl@...close.org>
Subject: Re: [PATCH net] openvswitch: compute needed headroom for internal vports

On Fri, Jan 8, 2016 at 4:42 PM, Jesse Gross <jesse@...nel.org> wrote:
> On Fri, Jan 8, 2016 at 2:53 PM, pravin shelar <pshelar@....org> wrote:
>> On Fri, Jan 8, 2016 at 1:50 PM, Paolo Abeni <pabeni@...hat.com> wrote:
>>> Currently the ovs internal vports always use a default needed_headroom.
>>> This leads to a skb head copy while xmitting on ovs swith via vport
>>> that add some kind of encapsulation (gre, geneve, etc.).
>>>
>>> This patch add book-keeping for the maximum needed_headroom used by
>>> the non internal vports in any dp, updating it on vport creation and
>>> deletion.
>>>
>>> Said value is than used as needed_headroom for internal vports,
>>> avoiding the above copy.
>>>
>> Why is this done only for internal devices? In most common case of
>> traffic the packet enters OVS from tap or other netdev type vport
>> device.
>
> How would you influence the allocation for non-internal devices?

Today there is no way of influencing this. But we could add new
skb-headroom parameter to netdev for packets that are received on the
device. This new parameter could be controlled from master devices
like OVS, Bridge, etc. To set this value we need new ndo operation. So
that it can work on devices like tap where it would just set this new
value and in case of ovs-internal or veth device, it can also update
needed_headroom.