netdev - Re: handing cloned frames to netif

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:	Sat, 12 Jan 2008 00:48:52 +0200
From:	"Tomas Winkler" <tomasw@...il.com>
To:	"Johannes Berg" <johannes@...solutions.net>
Cc:	netdev <netdev@...r.kernel.org>,
	"Ron Rindjunsky" <ron.rindjunsky@...el.com>,
	linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: handing cloned frames to netif_rx()?

On Jan 11, 2008 3:17 AM, Johannes Berg <johannes@...solutions.net> wrote:
> In 802.11n, there is a case where multiple data frames are received
> aggregated into a single frame (A-MSDU).
>
> Currently, we copy each of these frames out into their own skb, but
> because of the alignment with that etc. I started to think that we could
> simply pass up a clone of the original skb with start/length adjusted
> properly so that it windows only the contained packet.
>
> The buffer would be shared but the data within the original window
> (starting with the 802.3 header) could even be written to, it won't be
> needed again by mac80211 once it's handed off to netif_rx(). The skb
> will obviously have lots of head- and tailroom but that space would be
> part of other packets.
>
> Is it ok to do this? Will something freak out if we pass a cloned skb to
> netif_rx()?
>
This would be great even in regular case. 4965 has ability to deliver
more frames per receiving buffer
Because of A-MSDU we keeps 8K receiving buffers which are
underutilized when A-MSDU is not used.

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