On Thu, Jul 05, 2007 at 03:06:40PM +0200, Andi Kleen wrote:
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
private allocations. Woudn't this save some
On Thu, Jul 05, 2007 at 04:28:47PM +0400, Evgeniy Polyakov wrote:
Hi, Jarek.
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski ([EMAIL PROTECTED])
wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
On Fri, Jul 06, 2007 at 11:08:35AM +0200, Jarek Poplawski wrote:
...
BSDs were sometimes recommended for specific jobs like mail etc.
but usually linux better fitted the needs. Especially well linux
appeared for an internet gateway/router/firewall/antispam thing,
and the main reasons were:
Brice Goglin [EMAIL PROTECTED] writes:
I am trying to understand whether I can setup a skb destructor in my
code (which is basically a protocol above dev_queue_xmit() and co). From
what I see in many parts in the current kernel code, the protocol (I
mean, the one who actually creates the skb)
Andi Kleen wrote:
Brice Goglin [EMAIL PROTECTED] writes:
I am trying to understand whether I can setup a skb destructor in my
code (which is basically a protocol above dev_queue_xmit() and co). From
what I see in many parts in the current kernel code, the protocol (I
mean, the one who
On 05-07-2007 12:08, Andi Kleen wrote:
...
The traditional standpoint was that having your own large skb pools
is not recommended because you won't interact well with the
rest of the system running low on memory and you tieing up
memory.
Essentially you would recreate all the problems
Hi, Jarek.
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski ([EMAIL PROTECTED])
wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
private allocations. Woudn't this save some skb clonning,
copying or adding
On Thu, Jul 05, 2007 at 04:28:47PM +0400, Evgeniy Polyakov wrote:
Hi, Jarek.
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski ([EMAIL PROTECTED])
wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
private allocations. Woudn't this save some skb clonning,
copying or adding new fields for private infos?
The destructor method is set and used for skbs originating from the RDMA
driver sitting above cxgb3.
If these skbs never reach the normal sockets based stack it might be ok.
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
On Thu, Jul 05, 2007 at 03:06:40PM +0200, Andi Kleen wrote:
On Thu, Jul 05, 2007 at 02:28:50PM +0200, Jarek Poplawski wrote:
I wonder if it's very unsound to think about a one way list
of destructors. Of course, not owners could only clean their
private allocations. Woudn't this save some
Hi,
I am trying to understand whether I can setup a skb destructor in my
code (which is basically a protocol above dev_queue_xmit() and co). From
what I see in many parts in the current kernel code, the protocol (I
mean, the one who actually creates the skb) may setup a destructor.
However, I
On Wed, Jul 04, 2007 at 10:04:54AM +0200, Brice Goglin ([EMAIL PROTECTED])
wrote:
So, I'd like to have a clear statement about who's allowed to use a
destructor :)
That one who allocates skb - if it is socket layer, it sets own
socket destructor, netlink has own too and so on.
Thanks,
Brice
13 matches
Mail list logo
