linux-kernel - RE: [PATCH net-next RFC] net: increase LL_MAX

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Sep 2015 19:52:01 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	David Miller <davem@...emloft.net>
CC:	"David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
	"alexander.duyck@...il.com" <alexander.duyck@...il.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V



> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Thursday, September 17, 2015 11:52 AM
> To: KY Srinivasan <kys@...rosoft.com>
> Cc: David.Laight@...LAB.COM; alexander.duyck@...il.com; Haiyang Zhang
> <haiyangz@...rosoft.com>; vkuznets@...hat.com; netdev@...r.kernel.org;
> linux-kernel@...r.kernel.org; jasowang@...hat.com
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> 
> From: KY Srinivasan <kys@...rosoft.com>
> Date: Thu, 17 Sep 2015 15:14:05 +0000
> 
> > I think I can achieve my original goal of not having any allocation
> > in the send path by carefully using the memory available in the skb:
> 
> Please stop flat-out ignoring David L.'s suggestion.

I am sorry; I did not mean to convey that impression.

> 
> Have a pre-cooked ring of buffers for these descriptors that you can
> point the chip at.  No per-packet allocation is necessary at all.

Even if I had a ring of buffers, I would still need to manage the life cycle
of these buffers - selecting an unused one on the transmit path and marking
it used (atomically). Once the transmit completes (as indicated by the transmit complete
callback) this buffer needs to be marked free. I can certainly make these operations
efficient and  lock-free, but they are still at some level an allocation/free
operation albeit potentially more efficient than having the kernel allocate the memory.
 
> 
> If you play games with SKBs you will get burned.

I will implement Dave L's suggestion. However, I am curious as to why you would consider
my proposed usage of the skb headroom and the control buffer area in skb as non-standard
usage.

Regards,

K. Y 


  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/