From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 06:48:02 +0200
> >>
> # skb->real_dev, it is used in one place, in bonding device. Suggestion
> is to remove it and replace with an ugly per-cpu static variable (but
> still less ugly than keeping a useless pointer in struct sk_buff) We
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 06:32:33 +0200
> On Mon, Jul 11, 2005 at 07:44:47PM -0700, David S. Miller wrote:
> > From: Andi Kleen <[EMAIL PROTECTED]>
> > Date: 12 Jul 2005 04:25:49 +0200
> >
> > > What other plans do have? I think a lot of stuff could be moved
> >
On Mon, Jul 11, 2005 at 07:44:47PM -0700, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: 12 Jul 2005 04:25:49 +0200
>
> > What other plans do have? I think a lot of stuff could be moved
> > into ->cb, in particular tc_* and the HIPPI field.
>
> See:
>
> http://vger.k
On Mon, Jul 11, 2005 at 07:44:47PM -0700, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: 12 Jul 2005 04:25:49 +0200
>
> > What other plans do have? I think a lot of stuff could be moved
> > into ->cb, in particular tc_* and the HIPPI field.
>
> See:
>
> http://vger.k
From: Olaf Kirch <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 12:58:59 +0200
> In some cases, we may be generating packets with a source address that
> qualifies as martian. This can happen when we're in the middle of setting
> up or tearing down the network, and netfilter decides to reject a packet
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 04:39:25 +0400
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Applied, thanks Alexey.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Ok, this almost fully kills of skb->list. The thing that is missing
is that a couple ugly ATM drivers need to have their skb_unlink()
calls fixed to pass in the list head pointer as the second arg. I
gave it a quick shot, but I was unsuccessful. I can't even compile
one of them on my workstatio
On Mon, Jul 11, 2005 at 11:35:13AM -0400, Trent Jaeger wrote:
>
> Shall I submit the patch with the authorization?
Let me think about this for a while.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~h
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 12 Jul 2005 04:25:49 +0200
> What other plans do have? I think a lot of stuff could be moved
> into ->cb, in particular tc_* and the HIPPI field.
See:
http://vger.kernel.org/~davem/net_todo.html
there is an entry entitled "SKBs are too large",
"David S. Miller" <[EMAIL PROTECTED]> writes:
>
> As an aside, this reminds me that as part of my quest to make
> sk_buff smaller, I intend to walk across the tree and change
> all tests of the form:
What other plans do have? I think a lot of stuff could be moved
into ->cb, in particular tc_* and
From: Lennert Buytenhek <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 11:31:45 +0200
> Interesting material. What happens if there is an skb with paged
> data (say, a page cache page) on the sk_write_queue, and it ends up
> having to be retransmitted -- is it possible that the retransmit is
> sent w
Resurrect the sis190 driver.
The driver handles the integrated network device found on SiS 965L
chipset. It follows the classical (non-napi) interrupt-driven model
and provides minimal ethtool support.
The code comes from a heavy cleanup/rewrite of the original code
which was removed from the ker
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 17:00:56 -0700
> For incoming packets, the same sctp_chunk structure is used for all
> chunks in the packet whereas ulpevent is per-chunk. An sctp_chunk is
> allocated for a packet when we do a sctp_chunkify() in sctp_rcv(). We
> w
David S. Miller wrote:
>From: Chase Douglas <[EMAIL PROTECTED]>
>Date: Mon, 11 Jul 2005 12:33:46 -0500
>
>
>
>>I'm sorry, I made a careless mistake in choice of context. What this would
>>be useful for is applications where we want to seek ahead in one stream from
>>one connection. This is not m
On Mon, 2005-07-11 at 15:01 -0700, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Mon, 11 Jul 2005 09:56:10 -0700
>
> > An incoming skb can contain more than 1 user message(chunk) and
> > we do a clone for each message and store the per-message information
> > in the
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 09:56:10 -0700
> An incoming skb can contain more than 1 user message(chunk) and
> we do a clone for each message and store the per-message information
> in the ulpevent structure.
> Moreover, the ulpevent structure is already 34 b
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Fri, 8 Jul 2005 08:03:27 -0300
> Of course only the skbs created after the skb_alloc_extension() call would
> be valid for the subsystem
> that alloced the extension, would this be a problem?
It might be. It is entirely possible, for exam
From: Chase Douglas <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 15:14:44 -0500
> This may not mean much for normal use, but there are academic instances,
> especially in cluster computing, where saving many extra user-user
> copies can really add up.
So, basically, the useful situation is that the
Hi,
The following patch serie adds a sis190 driver to the kernel again.
Without an in-kernel driver, Google reveals that the sis190 experience
is anything but funny since it is based on a rather obsolescent and
unefficient driver. Thanks to a few people who have helped out testing
during the last
From: Chase Douglas <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 12:33:46 -0500
> I'm sorry, I made a careless mistake in choice of context. What this would
> be useful for is applications where we want to seek ahead in one stream from
> one connection. This is not meant for seeking somehow between
netconsole support
This stuff should be factored out of every driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN drivers/net/sis190.c~sis190-010 drivers/net/sis190.c
--- linux-2.6.13-rc2-gitXX/drivers/net/sis190.c~sis190-010 2005-07-11
20:27:48.238427212 +0200
+++ linux-2
Basic ethtool/mii support
Bug: disabling autonegotiation and setting the link parameters at the
same time does not provide the expected result. More investigation is
needed.
Note: past the initial probe/open time, the link is managed from user-space
or accessed through sis190_phy_task, i.e. in a
add MAINTAINER entry
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN MAINTAINERS~sis190-025 MAINTAINERS
--- linux-2.6.13-rc2-gitXX/MAINTAINERS~sis190-025 2005-07-11
20:45:13.543915938 +0200
+++ linux-2.6.13-rc2-gitXX-fr/MAINTAINERS 2005-07-11 20:47:57.485312440
+0200
@@
From: "Catalin(ux aka Dino) BOIE" <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 13:47:20 +0300 (EEST)
> Any chance to include all this documentation in
> Documentation/networking/skb/?
No, no intention of doing that. For the same reason we
don't put all of lartc.org into the kernel tree :)
-
To un
On 7/8/05 4:46 PM, "David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Chase Douglas <[EMAIL PROTECTED]>
> Date: Fri, 08 Jul 2005 16:12:12 -0500
>
>> This can be useful for programs such as mpi. In mpi, a server receives
>> results of computations from clients. However, the server cannot control
Mark Wallis wrote:
> Hi Pedro,
>
> On 10/07/2005, at 1:34 PM, Pedro Ramalhais wrote:
>
>
>> There's already a project on sourceforge,
>>
>> maybe you can check it for updates, or ask him directly.
>>
>
> This SF repository appears to be completely empty. Nothing in CVS.
> Nothing anywhere. Fran
On Fri, 2005-07-08 at 21:42 -0700, David S. Miller wrote:
> > > BTW, the rest of the SCTP input path should be audited to make sure
> > > any other use of the SKB control block on input does not spam the
> > > ipv4/ipv6 parameter area (struct inet_skb_parm and struct
> > > inet6_skb_parm). That mu
Modifying the flowi structure will not help, as we would need to compute
the sid of the request which is tantamount to authorization.
Since this code simply iterates through the existing entries,
authorization of a match is appropriate. The only anxiety I have is that
the object is untyped, an
Feyd wrote:
On Mon, 11 Jul 2005 09:16:21 +0200 (CEST)
Ben Greear <[EMAIL PROTECTED]> wrote:
If you do find yourself needing to grow the skb, it can be done,
but it is not too efficient. Look at the 8021q vlan transmit
path code...it will insert it's 4 byte header in certain cases, and
has log
Hi,
In some cases, we may be generating packets with a source address that
qualifies as martian. This can happen when we're in the middle of setting
up or tearing down the network, and netfilter decides to reject a packet
with an RST. The routing code would detect the martian, and try to
print a
On Sun, 10 Jul 2005, David S. Miller wrote:
I've updated the SKB tutorial a little bit today, in particular
I added coverage of non-linear data areas to the SKB data
handling tutorial page at:
http://vger.kernel.org/~davem/skb_data.html
I'll probably start working on the TCP packet o
On Sun, Jul 10, 2005 at 10:29:41PM -0700, David S. Miller wrote:
> Ok, I went a little bananas with the diagrams, but here
> goes nothing :-)
>
> http://vger.kernel.org/~davem/tcp_output.html
Interesting material. What happens if there is an skb with paged
data (say, a page cache page) on
On Mon, 11 Jul 2005 09:16:21 +0200 (CEST)
Ben Greear <[EMAIL PROTECTED]> wrote:
> If you do find yourself needing to grow the skb, it can be done,
> but it is not too efficient. Look at the 8021q vlan transmit
> path code...it will insert it's 4 byte header in certain cases, and
> has logic to gr
David S. Miller wrote:
From: Feyd <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 07:43:10 +0200
can I assume that hard_start_xmit will always get skbs with hard_header_len
reserved? I need two more bytes at the start of the packet and I'm getting
spurious panics in skb_push.
Typically, no. ->h
Tommy Christensen píše v Pá 01. 07. 2005 v 18:45 +0200:
> OK, I can see what's happening here. eth0 doesn't detect link-up until
> after a few seconds, so when the vlan interface is opened immediately
> after eth0 has been opened, it inherits the link-down state. Subsequently
> the vlan interface
35 matches
Mail list logo
