* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Kumar Gala @ 2006-03-28 23:03 UTC (permalink / raw)
To: Andrew Grover; +Cc: Chris Leech, linux kernel mailing list, netdev
In-Reply-To: <c0a09e5c0603281401uaeea6aci57054aef444a5e1@mail.gmail.com>
On Mar 28, 2006, at 4:01 PM, Andrew Grover wrote:
> On 3/28/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>>> Also, what do you think about adding an operation type (MEMCPY,
>>>> XOR,
>>>> CRYPTO_AES, etc). We can than validate if the operation type
>>>> expected is supported by the devices that exist.
>>>
>>> No objections, but this speculative support doesn't need to be in
>>> our
>>> initial patchset.
>>
>> I don't consider it speculative. The patch is for a generic DMA
>> engine interface. That interface should encompass all users. I have
>> a security/crypto DMA engine that I'd like to front with the generic
>> DMA interface today. Also, I believe there is another Intel group
>> with an XOR engine that had a similar concept called ADMA posted a
>> while ago.
>
> Please submit patches then. We will be doing another rev of the I/OAT
> patch very soon, which you will be able to patch against. Or, once the
> patch gets in mainline then we can enhance it. Code in the Linux
> kernel is never "done", and the burden of implementing additional
> functionality falls on those who want it.
I completely understand that. However, I think putting something
into mainline that only works or solves the particular problem you
have is a bad idea. I'll provide patches for the changes I'd like to
see. However, I figured a little discussion on the subject before I
went off an spent time on it was worth while.
>> Can you explain what the semantics are.
>>
>> It's been a little while since I posted so my thoughts on the subject
>> are going to take a little while to come back to me :)
>
> Yeah. Basically you register as a DMA client, and say how many DMA
> channels you want. Our net_dma patch for example uses multiple
> channels to help lock contention. Then when channels are available
> (i.e. a DMA device added or another client gives them up) then you get
> a callback. If the channel goes away (i.e. DMA device is removed
> (theoretically possible but practically never happens) or *you* are
> going away and change your request to 0 channels) then you get a
> remove callback.
Do you only get callback when a channel is available? How do you
decide to do to provide PIO to the client?
A client should only request multiple channel to handle multiple
concurrent operations.
> This gets around the problem of DMA clients registering (and therefore
> not getting) channels simply because they init before the DMA device
> is discovered.
What do you expect to happen in a system in which the channels are
over subscribed?
Do you expect the DMA device driver to handle scheduling of channels
between multiple clients?
- kumar
^ permalink raw reply
* [PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
From: Linas Vepstas @ 2006-03-28 22:36 UTC (permalink / raw)
To: tsbogend, donf; +Cc: jklewis, linuxppc-dev, linux-kernel, netdev
Please sign-off/ack/apply and/or forward upstream.
[PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
The comments concerning how the pcnet32 ethernet device driver selects
the MAC addr to use are incorrect. A recent patch (in the last 3 months)
changed how the code worked, but did not change the comments.
Side comment: the new behaviour is good; I've got a pcnet32 card which
powers up with garbage in the CSR's, and a good MAC addr in the PROM.
Signed-off-by: Linas Vepstas <linas@linas.org>
----
drivers/net/pcnet32.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-git6/drivers/net/pcnet32.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/pcnet32.c 2006-03-23 12:21:41.000000000 -0600
+++ linux-2.6.16-git6/drivers/net/pcnet32.c 2006-03-28 16:08:23.398158717 -0600
@@ -1167,8 +1167,8 @@ pcnet32_probe1(unsigned long ioaddr, int
* station address PROM at the base address and programmed into the
* "Physical Address Registers" CSR12-14.
* As a precautionary measure, we read the PROM values and complain if
- * they disagree with the CSRs. Either way, we use the CSR values, and
- * double check that they are valid.
+ * they disagree with the CSRs. If they miscompare, and the PROM addr
+ * is valid, then the PROM addr is used.
*/
for (i = 0; i < 3; i++) {
unsigned int val;
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Andrew Grover @ 2006-03-28 22:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Chris Leech, linux kernel mailing list, netdev
In-Reply-To: <D760971F-3C6A-400B-99EA-E95358B37F82@kernel.crashing.org>
On 3/28/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Also, what do you think about adding an operation type (MEMCPY, XOR,
> >> CRYPTO_AES, etc). We can than validate if the operation type
> >> expected is supported by the devices that exist.
> >
> > No objections, but this speculative support doesn't need to be in our
> > initial patchset.
>
> I don't consider it speculative. The patch is for a generic DMA
> engine interface. That interface should encompass all users. I have
> a security/crypto DMA engine that I'd like to front with the generic
> DMA interface today. Also, I believe there is another Intel group
> with an XOR engine that had a similar concept called ADMA posted a
> while ago.
Please submit patches then. We will be doing another rev of the I/OAT
patch very soon, which you will be able to patch against. Or, once the
patch gets in mainline then we can enhance it. Code in the Linux
kernel is never "done", and the burden of implementing additional
functionality falls on those who want it.
> Can you explain what the semantics are.
>
> It's been a little while since I posted so my thoughts on the subject
> are going to take a little while to come back to me :)
Yeah. Basically you register as a DMA client, and say how many DMA
channels you want. Our net_dma patch for example uses multiple
channels to help lock contention. Then when channels are available
(i.e. a DMA device added or another client gives them up) then you get
a callback. If the channel goes away (i.e. DMA device is removed
(theoretically possible but practically never happens) or *you* are
going away and change your request to 0 channels) then you get a
remove callback.
This gets around the problem of DMA clients registering (and therefore
not getting) channels simply because they init before the DMA device
is discovered.
Regards -- Andy
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Kumar Gala @ 2006-03-28 18:58 UTC (permalink / raw)
To: Andrew Grover; +Cc: Chris Leech, linux kernel mailing list, netdev
In-Reply-To: <c0a09e5c0603281044i57730c66ye08c45aadd352cf8@mail.gmail.com>
On Mar 28, 2006, at 12:44 PM, Andrew Grover wrote:
> On 3/16/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>> It would seem that when a client registers (or shortly there after
>> when they call dma_async_client_chan_request()) they would expect to
>> get the number of channels they need by some given time period.
>>
>> For example, lets say a client registers but no dma device exists.
>> They will never get called to be aware of this condition.
>>
>> I would think most clients would either spin until they have all the
>> channels they need or fall back to a non-async mechanism.
>
> Clients *are* expected to fall back to non-async if they are not given
> channels. The reason it was implemented with callbacks for
> added/removed was that the client may be initializing before the
> channels are enumerated. For example, the net subsystem will ask for
> channels and not get them for a while, until the ioatdma PCI device is
> found and its driver loads. In this scenario, we'd like the net
> subsystem to be given these channels, instead of them going unused.
Fair, I need to think on that a little more.
>> Also, what do you think about adding an operation type (MEMCPY, XOR,
>> CRYPTO_AES, etc). We can than validate if the operation type
>> expected is supported by the devices that exist.
>
> No objections, but this speculative support doesn't need to be in our
> initial patchset.
I don't consider it speculative. The patch is for a generic DMA
engine interface. That interface should encompass all users. I have
a security/crypto DMA engine that I'd like to front with the generic
DMA interface today. Also, I believe there is another Intel group
with an XOR engine that had a similar concept called ADMA posted a
while ago.
http://marc.theaimsgroup.com/?t=112603120100004&r=1&w=2
>> Shouldn't we also have a dma_async_client_chan_free()?
>
> Well we could just define it to be chan_request(0) but it doesn't seem
> to be needed. Also, the allocation mechanism we have for channels is
> different from alloc/free's semantics, so it may be best to not muddy
> the water in this area.
Can you explain what the semantics are.
It's been a little while since I posted so my thoughts on the subject
are going to take a little while to come back to me :)
- kumar
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Andrew Grover @ 2006-03-28 18:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Chris Leech, linux kernel mailing list, netdev
In-Reply-To: <2FF801BB-F96C-4864-AC44-09B4B92531F7@kernel.crashing.org>
On 3/16/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> It would seem that when a client registers (or shortly there after
> when they call dma_async_client_chan_request()) they would expect to
> get the number of channels they need by some given time period.
>
> For example, lets say a client registers but no dma device exists.
> They will never get called to be aware of this condition.
>
> I would think most clients would either spin until they have all the
> channels they need or fall back to a non-async mechanism.
Clients *are* expected to fall back to non-async if they are not given
channels. The reason it was implemented with callbacks for
added/removed was that the client may be initializing before the
channels are enumerated. For example, the net subsystem will ask for
channels and not get them for a while, until the ioatdma PCI device is
found and its driver loads. In this scenario, we'd like the net
subsystem to be given these channels, instead of them going unused.
> Also, what do you think about adding an operation type (MEMCPY, XOR,
> CRYPTO_AES, etc). We can than validate if the operation type
> expected is supported by the devices that exist.
No objections, but this speculative support doesn't need to be in our
initial patchset.
> Shouldn't we also have a dma_async_client_chan_free()?
Well we could just define it to be chan_request(0) but it doesn't seem
to be needed. Also, the allocation mechanism we have for channels is
different from alloc/free's semantics, so it may be best to not muddy
the water in this area.
Regards -- Andy
^ permalink raw reply
* 2.6.16, 3com: transmit timed out, tx_status 00 status 8000
From: John Bäckstrand @ 2006-03-27 23:25 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, linux-net
Ive been seeing stuff in dmesg with very recent kernels:
NETDEV WATCHDOG: 3com: transmit timed out
3com: transmit timed out, tx_status 00 status 8000.
diagnostics: net 04fa media 8880 dma 000000a0 fifo 0000
Flags; bus-master 1, dirty 67260778(10) current 67260794(10)
Transmit list 2f6758e0 vs. ef675840.
3com: command 0x3002 did not complete! Status=0x9000
0: @ef675200 length 80000036 status 00000036
1: @ef6752a0 length 80000042 status 00000042
2: @ef675340 length 8000028c status 0000028c
3: @ef6753e0 length 800005d6 status 000005d6
4: @ef675480 length 800005ea status 000005ea
5: @ef675520 length 800005ba status 000005ba
6: @ef6755c0 length 8000028c status 0000028c
7: @ef675660 length 800005d6 status 000005d6
8: @ef675700 length 800005ea status 800005ea
9: @ef6757a0 length 800005d6 status 800005d6
10: @ef675840 length 80000036 status 00010036
11: @ef6758e0 length 80000036 status 00000036
12: @ef675980 length 80000036 status 00000036
13: @ef675a20 length 80000036 status 00000036
14: @ef675ac0 length 80000036 status 00000036
15: @ef675b60 length 80000036 status 00000036
Any ideas at all? Seems to happen mostly when doing heavy downloading.
I think this did not happen a few versions ago, I know it happened with
2.6.16-rc6, and 2.6.16. I donk think it used to happen on .14/.15 and
earlier though.
The card is a 3c905.
0000:00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
[Tornado] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32
bytes)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 9000 [size=128]
Region 1: Memory at e3000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at 40000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
(I see there has been 3com-related patches in -git, should I try this?
Any chance of them helping?
---
John Bäckstrand
^ permalink raw reply
* Re: [2.6 patch] PCMCIA_SPECTRUM must select FW_LOADER
From: John W. Linville @ 2006-03-27 21:56 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Alexander E. Patrakov, LKML, netdev
In-Reply-To: <20060324165619.GG22727@stusta.de>
On Fri, Mar 24, 2006 at 05:56:19PM +0100, Adrian Bunk wrote:
> PCMCIA_SPECTRUM must select FW_LOADER.
>
> Reported by "Alexander E. Patrakov" <patrakov@ums.usu.ru>.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Merged to the 'upstream' branch of wireless-2.6.
Thanks!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: 32bit compat for rtnetlink wireless extensions?
From: Jean Tourrilhes @ 2006-03-27 21:17 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev, John W. Linville, linux-kernel
In-Reply-To: <200603272310.44692.arnd@arndb.de>
On Mon, Mar 27, 2006 at 11:10:44PM +0200, Arnd Bergmann wrote:
> Am Monday 27 March 2006 20:42 schrieb Jean Tourrilhes:
> > Actually, when things are passed over RtNetlink, the pointer
> > is removed, and the content of IW_HEADER_TYPE_POINT is moved to not
> > leave a gap.
>
> Ah, that makes sense, thanks for the explanation.
>
> So if the wireless ioctl interface ever got retired, that code could
> get simplified a lot to just pass around a flat data structure, right?
>
> Arnd <><
Actually, it could be removed *now*. You would just have to
fix all wireless drivers in existence. I will scratch my head to see
if we could plan a smooth transition.
Jean
^ permalink raw reply
* Re: 32bit compat for rtnetlink wireless extensions?
From: Arnd Bergmann @ 2006-03-27 21:10 UTC (permalink / raw)
To: jt; +Cc: netdev, John W. Linville, linux-kernel
In-Reply-To: <20060327184242.GC31478@bougret.hpl.hp.com>
Am Monday 27 March 2006 20:42 schrieb Jean Tourrilhes:
> Actually, when things are passed over RtNetlink, the pointer
> is removed, and the content of IW_HEADER_TYPE_POINT is moved to not
> leave a gap.
Ah, that makes sense, thanks for the explanation.
So if the wireless ioctl interface ever got retired, that code could
get simplified a lot to just pass around a flat data structure, right?
Arnd <><
^ permalink raw reply
* Re: 32bit compat for rtnetlink wireless extensions?
From: Jean Tourrilhes @ 2006-03-27 18:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: netdev, John W. Linville, linux-kernel
In-Reply-To: <200603261408.48766.arnd@arndb.de>
On Sun, Mar 26, 2006 at 02:08:48PM +0200, Arnd Bergmann wrote:
> I stumbled over the 'WE-20 for kernel 2.6.16' and afaict, there is no
> way that IW_HEADER_TYPE_POINT rtnetlink messages can work when using
> 32 bit user tools on a 64 bit kernel.
Please check again ;-) I agree that it's not obvious...
> For the ioctl inteface, this gets handled using the do_wireless_ioctl
> function in fs/compat_ioctl.c, but we don't have a way to convert
> netlink data -- it is supposed to always be compatible between
> 32 and 64 bit.
>
> What is the reason for having IW_HEADER_TYPE_POINT in the first place?
> Does that reason apply to both the ioctl and the netlink interface, or
> can the netlink transport for wireless commands be changed so it
> does not need user space pointers?
Actually, when things are passed over RtNetlink, the pointer
is removed, and the content of IW_HEADER_TYPE_POINT is moved to not
leave a gap.
The actual code for the commands is a little bit complex,
especially that the buffer is "optimised". But, if you check for the
comments, you will find it. Instead, you may want to check the code
for the event, where I do the same, and which is easier to read.
The function is iwe_stream_add_point(), and you will find it
in include/net/iw_handler.h. Copy below...
I was toying with the idea of changing the
IW_HEADER_TYPE_POINT struct itself, but I discarded that because the
amount of fixing in the driver that would require.
> Arnd <><
Thanks for the quick review, have fun...
Jean
/*------------------------------------------------------------------*/
/*
* Wrapper to add an short Wireless Event containing a pointer to a
* stream of events.
*/
static inline char *
iwe_stream_add_point(char * stream, /* Stream of events */
char * ends, /* End of stream */
struct iw_event *iwe, /* Payload length + flags */
char * extra) /* More payload */
{
int event_len = IW_EV_POINT_LEN + iwe->u.data.length;
/* Check if it's possible */
if(likely((stream + event_len) < ends)) {
iwe->len = event_len;
memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
memcpy(stream + IW_EV_LCP_LEN,
((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
IW_EV_POINT_LEN - IW_EV_LCP_LEN);
memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length);
stream += event_len;
}
return stream;
}
^ permalink raw reply
* Re: [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
From: Pavel Roskin @ 2006-03-27 17:12 UTC (permalink / raw)
To: John W. Linville
Cc: Sebastian, Jeff Garzik, Linux Kernel Mailing List, linux,
Netdev List
In-Reply-To: <20060327164844.GF14403@tuxdriver.com>
On Mon, 2006-03-27 at 11:48 -0500, John W. Linville wrote:
> > this patch seems to break my setup. The hostap_cs driver included in
> > kernel 2.6.16 does not detect my Prism 2 WLAN card anymore, although it
> > is *not* Orinoco. With 2.6.15.5 it still worked.
It mean hostap_cs was identifying the card solely by its numeric ID
(0x0156, 0x0002) instead of the vendor strings. Since that particular
numeric ID was used both by cards that are supported by hostap_cs and
those that are not, it cannot be used in hostap_cs.
Sebastian, please send me the output of "pccardctl ident" and I'll
submit the patch for hostap_cs.
> This patch didn't come through me, so I don't know much about it.
> Hopefully Pavel or Dominik can comment?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
From: John W. Linville @ 2006-03-27 16:48 UTC (permalink / raw)
To: Sebastian
Cc: Jeff Garzik, Linux Kernel Mailing List, linux, Netdev List,
proski
In-Reply-To: <1143459885.9691.6.camel@coruscant.datenknoten.de>
On Mon, Mar 27, 2006 at 01:44:44PM +0200, Sebastian wrote:
> > commit 40e3cad61197fce63853e778db020f7637d988f2
> > tree 6e086c930e1aef0bb24eb61af42d1f3c1fb7d38c
> > parent f0892b89e3c19c7d805825ca12511d26dcdf6415
> > author Pavel Roskin <proski@gnu.org> Tue, 28 Feb 2006 11:18:31 -0500
> > committer Dominik Brodowski <linux@dominikbrodowski.net> Wed, 01 Mar
> > 2006 11:12:00 +0100
> >
> > [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
> >
> > Don't just use cards with PCMCIA ID 0x0156, 0x0002. Make sure that
> > the vendor string is "Intersil" or "INTERSIL"
> >
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> > Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
> >
> > drivers/net/wireless/hostap/hostap_cs.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletion(-)
> this patch seems to break my setup. The hostap_cs driver included in
> kernel 2.6.16 does not detect my Prism 2 WLAN card anymore, although it
> is *not* Orinoco. With 2.6.15.5 it still worked.
This patch didn't come through me, so I don't know much about it.
Hopefully Pavel or Dominik can comment?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
From: Peter Horton @ 2006-03-27 12:39 UTC (permalink / raw)
To: Martin Michlmayr
Cc: P. Horton, Geert Uytterhoeven, netdev, Linux/MIPS Development,
Francois Romieu
In-Reply-To: <20060327070112.GA10906@deprecation.cyrius.com>
Martin Michlmayr wrote:
> * Francois Romieu <romieu@fr.zoreil.com> [2006-03-09 23:44]:
>
>>> So when compiling for Cobalt, we work around the hardware bug, while for other
>>> platforms, we just disable MWI?
>>>
>>> Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
>>> work around the bug?
>>>
>> Of course it is possible but it is not the same semantic as the initial
>> patch (not that I know if it is right or not).
>>
>> So:
>> - does the issue exist beyond Cobalt hosts ?
>> - is the fix Cobalt-only ?
>>
>
> I don't think anyone has replied to this message yet. My
> understanding is that it's not Cobalt only but a problem in a specific
> revision of the chip, which the Cobalt happens to use. However, I'd
> be glad if somone else could comment. Peter, you read the errata
> right?
>
According to the errata it applies to all DEC 21143-PD and 21143-TD
which are the chips with the revision code 0x41 (65). The errata states
the receive buffers should not end on a cache aligned boundary when
using MWI otherwise the receiver will not close the last descriptor.
P.
^ permalink raw reply
* Re: [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
From: Sebastian @ 2006-03-27 11:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel Mailing List, linux, Netdev List
In-Reply-To: <44063023.9010603@pobox.com>
> commit 40e3cad61197fce63853e778db020f7637d988f2
> tree 6e086c930e1aef0bb24eb61af42d1f3c1fb7d38c
> parent f0892b89e3c19c7d805825ca12511d26dcdf6415
> author Pavel Roskin <proski@gnu.org> Tue, 28 Feb 2006 11:18:31 -0500
> committer Dominik Brodowski <linux@dominikbrodowski.net> Wed, 01 Mar
> 2006 11:12:00 +0100
>
> [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
>
> Don't just use cards with PCMCIA ID 0x0156, 0x0002. Make sure that
> the vendor string is "Intersil" or "INTERSIL"
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
> drivers/net/wireless/hostap/hostap_cs.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletion(-)
Hello,
this patch seems to break my setup. The hostap_cs driver included in
kernel 2.6.16 does not detect my Prism 2 WLAN card anymore, although it
is *not* Orinoco. With 2.6.15.5 it still worked.
FYI:
pccardctl info
PRODID_1=""
PRODID_2="Link DWL-650 11Mbps WLAN Card"
PRODID_3="Version 01.02"
PRODID_4=""
MANFID=0156,0002
FUNCID=6
Sebastian
^ permalink raw reply
* [PATCH] deinline some larger functions from netdevice.h
From: Denis Vlasenko @ 2006-03-27 11:19 UTC (permalink / raw)
To: linux-kernel, netdev, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On a allyesconfig'ured kernel:
Size Uses Wasted Name and definition
===== ==== ====== ================================================
95 162 12075 netif_wake_queue include/linux/netdevice.h
129 86 9265 dev_kfree_skb_any include/linux/netdevice.h
127 56 5885 netif_device_attach include/linux/netdevice.h
73 86 4505 dev_kfree_skb_irq include/linux/netdevice.h
46 60 1534 netif_device_detach include/linux/netdevice.h
119 16 1485 __netif_rx_schedule include/linux/netdevice.h
143 5 492 netif_rx_schedule include/linux/netdevice.h
81 7 366 netif_schedule include/linux/netdevice.h
netif_wake_queue is big because __netif_schedule is a big inline:
static inline void __netif_schedule(struct net_device *dev)
{
if (!test_and_set_bit(__LINK_STATE_SCHED, &dev->state)) {
unsigned long flags;
struct softnet_data *sd;
local_irq_save(flags);
sd = &__get_cpu_var(softnet_data);
dev->next_sched = sd->output_queue;
sd->output_queue = dev;
raise_softirq_irqoff(NET_TX_SOFTIRQ);
local_irq_restore(flags);
}
}
static inline void netif_wake_queue(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap())
return;
#endif
if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state))
__netif_schedule(dev);
}
By de-inlining __netif_schedule we are saving a lot of text
at each callsite of netif_wake_queue and netif_schedule.
__netif_rx_schedule is also big, and it makes more sense to keep
both of them out of line.
Patch also deinlines dev_kfree_skb_any. We can deinline dev_kfree_skb_irq
instead... oh well.
netif_device_attach/detach are not hot paths, we can deinline them too.
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: netdevice.patch --]
[-- Type: text/x-diff, Size: 4491 bytes --]
diff -urpN linux-2.6.16.org/include/linux/netdevice.h linux-2.6.16.deinline2/include/linux/netdevice.h
--- linux-2.6.16.org/include/linux/netdevice.h Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline2/include/linux/netdevice.h Mon Mar 27 13:46:15 2006
@@ -594,20 +594,7 @@ DECLARE_PER_CPU(struct softnet_data,soft
#define HAVE_NETIF_QUEUE
-static inline void __netif_schedule(struct net_device *dev)
-{
- if (!test_and_set_bit(__LINK_STATE_SCHED, &dev->state)) {
- unsigned long flags;
- struct softnet_data *sd;
-
- local_irq_save(flags);
- sd = &__get_cpu_var(softnet_data);
- dev->next_sched = sd->output_queue;
- sd->output_queue = dev;
- raise_softirq_irqoff(NET_TX_SOFTIRQ);
- local_irq_restore(flags);
- }
-}
+extern void __netif_schedule(struct net_device *dev);
static inline void netif_schedule(struct net_device *dev)
{
@@ -671,13 +658,7 @@ static inline void dev_kfree_skb_irq(str
/* Use this variant in places where it could be invoked
* either from interrupt or non-interrupt context.
*/
-static inline void dev_kfree_skb_any(struct sk_buff *skb)
-{
- if (in_irq() || irqs_disabled())
- dev_kfree_skb_irq(skb);
- else
- dev_kfree_skb(skb);
-}
+extern void dev_kfree_skb_any(struct sk_buff *skb);
#define HAVE_NETIF_RX 1
extern int netif_rx(struct sk_buff *skb);
@@ -735,22 +716,9 @@ static inline int netif_device_present(s
return test_bit(__LINK_STATE_PRESENT, &dev->state);
}
-static inline void netif_device_detach(struct net_device *dev)
-{
- if (test_and_clear_bit(__LINK_STATE_PRESENT, &dev->state) &&
- netif_running(dev)) {
- netif_stop_queue(dev);
- }
-}
+extern void netif_device_detach(struct net_device *dev);
-static inline void netif_device_attach(struct net_device *dev)
-{
- if (!test_and_set_bit(__LINK_STATE_PRESENT, &dev->state) &&
- netif_running(dev)) {
- netif_wake_queue(dev);
- __netdev_watchdog_up(dev);
- }
-}
+extern void netif_device_attach(struct net_device *dev);
/*
* Network interface message level settings
@@ -818,20 +786,7 @@ static inline int netif_rx_schedule_prep
* already been called and returned 1.
*/
-static inline void __netif_rx_schedule(struct net_device *dev)
-{
- unsigned long flags;
-
- local_irq_save(flags);
- dev_hold(dev);
- list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
- if (dev->quota < 0)
- dev->quota += dev->weight;
- else
- dev->quota = dev->weight;
- __raise_softirq_irqoff(NET_RX_SOFTIRQ);
- local_irq_restore(flags);
-}
+extern void __netif_rx_schedule(struct net_device *dev);
/* Try to reschedule poll. Called by irq handler. */
diff -urpN linux-2.6.16.org/net/core/dev.c linux-2.6.16.deinline2/net/core/dev.c
--- linux-2.6.16.org/net/core/dev.c Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline2/net/core/dev.c Mon Mar 27 13:47:00 2006
@@ -1073,6 +1073,70 @@ void dev_queue_xmit_nit(struct sk_buff *
rcu_read_unlock();
}
+
+void __netif_schedule(struct net_device *dev)
+{
+ if (!test_and_set_bit(__LINK_STATE_SCHED, &dev->state)) {
+ unsigned long flags;
+ struct softnet_data *sd;
+
+ local_irq_save(flags);
+ sd = &__get_cpu_var(softnet_data);
+ dev->next_sched = sd->output_queue;
+ sd->output_queue = dev;
+ raise_softirq_irqoff(NET_TX_SOFTIRQ);
+ local_irq_restore(flags);
+ }
+}
+EXPORT_SYMBOL(__netif_schedule);
+
+void __netif_rx_schedule(struct net_device *dev)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ dev_hold(dev);
+ list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
+ if (dev->quota < 0)
+ dev->quota += dev->weight;
+ else
+ dev->quota = dev->weight;
+ __raise_softirq_irqoff(NET_RX_SOFTIRQ);
+ local_irq_restore(flags);
+}
+EXPORT_SYMBOL(__netif_rx_schedule);
+
+void dev_kfree_skb_any(struct sk_buff *skb)
+{
+ if (in_irq() || irqs_disabled())
+ dev_kfree_skb_irq(skb);
+ else
+ dev_kfree_skb(skb);
+}
+EXPORT_SYMBOL(dev_kfree_skb_any);
+
+
+/* Hot-plugging. */
+void netif_device_detach(struct net_device *dev)
+{
+ if (test_and_clear_bit(__LINK_STATE_PRESENT, &dev->state) &&
+ netif_running(dev)) {
+ netif_stop_queue(dev);
+ }
+}
+EXPORT_SYMBOL(netif_device_detach);
+
+void netif_device_attach(struct net_device *dev)
+{
+ if (!test_and_set_bit(__LINK_STATE_PRESENT, &dev->state) &&
+ netif_running(dev)) {
+ netif_wake_queue(dev);
+ __netdev_watchdog_up(dev);
+ }
+}
+EXPORT_SYMBOL(netif_device_attach);
+
+
/*
* Invalidate hardware checksum when packet is to be mangled, and
* complete checksum manually on outgoing path.
^ permalink raw reply
* [PATCH] deinline 200+ byte inlines in sock.h
From: Denis Vlasenko @ 2006-03-27 7:21 UTC (permalink / raw)
To: linux-kernel, netdev
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
Sizes in bytes (allyesconfig, i386) and files where those inlines
are used:
238 sock_queue_rcv_skb 2.6.16/net/x25/x25_in.o
238 sock_queue_rcv_skb 2.6.16/net/rose/rose_in.o
238 sock_queue_rcv_skb 2.6.16/net/packet/af_packet.o
238 sock_queue_rcv_skb 2.6.16/net/netrom/nr_in.o
238 sock_queue_rcv_skb 2.6.16/net/llc/llc_sap.o
238 sock_queue_rcv_skb 2.6.16/net/llc/llc_conn.o
238 sock_queue_rcv_skb 2.6.16/net/irda/af_irda.o
238 sock_queue_rcv_skb 2.6.16/net/ipx/af_ipx.o
238 sock_queue_rcv_skb 2.6.16/net/ipv6/udp.o
238 sock_queue_rcv_skb 2.6.16/net/ipv6/raw.o
238 sock_queue_rcv_skb 2.6.16/net/ipv4/udp.o
238 sock_queue_rcv_skb 2.6.16/net/ipv4/raw.o
238 sock_queue_rcv_skb 2.6.16/net/ipv4/ipmr.o
238 sock_queue_rcv_skb 2.6.16/net/econet/econet.o
238 sock_queue_rcv_skb 2.6.16/net/econet/af_econet.o
238 sock_queue_rcv_skb 2.6.16/net/bluetooth/sco.o
238 sock_queue_rcv_skb 2.6.16/net/bluetooth/l2cap.o
238 sock_queue_rcv_skb 2.6.16/net/bluetooth/hci_sock.o
238 sock_queue_rcv_skb 2.6.16/net/ax25/ax25_in.o
238 sock_queue_rcv_skb 2.6.16/net/ax25/af_ax25.o
238 sock_queue_rcv_skb 2.6.16/net/appletalk/ddp.o
238 sock_queue_rcv_skb 2.6.16/drivers/net/pppoe.o
276 sk_receive_skb 2.6.16/net/decnet/dn_nsp_in.o
276 sk_receive_skb 2.6.16/net/dccp/ipv6.o
276 sk_receive_skb 2.6.16/net/dccp/ipv4.o
276 sk_receive_skb 2.6.16/net/dccp/dccp_ipv6.o
276 sk_receive_skb 2.6.16/drivers/net/pppoe.o
209 sk_dst_check 2.6.16/net/ipv6/ip6_output.o
209 sk_dst_check 2.6.16/net/ipv4/udp.o
209 sk_dst_check 2.6.16/net/decnet/dn_nsp_out.o
Should I also attack sock_recv_timestamp() etc?
Large inlines with multiple callers:
Size Uses Wasted Name and definition
===== ==== ====== ================================================
238 21 4360 sock_queue_rcv_skb include/net/sock.h
109 10 801 sock_recv_timestamp include/net/sock.h
276 4 768 sk_receive_skb include/net/sock.h
94 8 518 __sk_dst_check include/net/sock.h
209 3 378 sk_dst_check include/net/sock.h
131 4 333 sk_setup_caps include/net/sock.h
152 2 132 sk_stream_alloc_pskb include/net/sock.h
125 2 105 sk_stream_writequeue_purge include/net/sock.h
--
vda
[-- Attachment #2: sock.patch --]
[-- Type: text/x-diff, Size: 5483 bytes --]
diff -urpN linux-2.6.16.org/include/net/sock.h linux-2.6.16.deinline/include/net/sock.h
--- linux-2.6.16.org/include/net/sock.h Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline/include/net/sock.h Mon Mar 27 09:55:12 2006
@@ -926,28 +926,7 @@ static inline void sock_put(struct sock
sk_free(sk);
}
-static inline int sk_receive_skb(struct sock *sk, struct sk_buff *skb)
-{
- int rc = NET_RX_SUCCESS;
-
- if (sk_filter(sk, skb, 0))
- goto discard_and_relse;
-
- skb->dev = NULL;
-
- bh_lock_sock(sk);
- if (!sock_owned_by_user(sk))
- rc = sk->sk_backlog_rcv(sk, skb);
- else
- sk_add_backlog(sk, skb);
- bh_unlock_sock(sk);
-out:
- sock_put(sk);
- return rc;
-discard_and_relse:
- kfree_skb(skb);
- goto out;
-}
+extern int sk_receive_skb(struct sock *sk, struct sk_buff *skb);
/* Detach socket from process context.
* Announce socket dead, detach it from wait queue and inode.
@@ -1032,33 +1011,9 @@ sk_dst_reset(struct sock *sk)
write_unlock(&sk->sk_dst_lock);
}
-static inline struct dst_entry *
-__sk_dst_check(struct sock *sk, u32 cookie)
-{
- struct dst_entry *dst = sk->sk_dst_cache;
-
- if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) {
- sk->sk_dst_cache = NULL;
- dst_release(dst);
- return NULL;
- }
-
- return dst;
-}
-
-static inline struct dst_entry *
-sk_dst_check(struct sock *sk, u32 cookie)
-{
- struct dst_entry *dst = sk_dst_get(sk);
-
- if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) {
- sk_dst_reset(sk);
- dst_release(dst);
- return NULL;
- }
+extern struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie);
- return dst;
-}
+extern struct dst_entry *sk_dst_check(struct sock *sk, u32 cookie);
static inline void sk_setup_caps(struct sock *sk, struct dst_entry *dst)
{
@@ -1128,45 +1083,7 @@ extern void sk_reset_timer(struct sock *
extern void sk_stop_timer(struct sock *sk, struct timer_list* timer);
-static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
-{
- int err = 0;
- int skb_len;
-
- /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
- number of warnings when compiling with -W --ANK
- */
- if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
- (unsigned)sk->sk_rcvbuf) {
- err = -ENOMEM;
- goto out;
- }
-
- /* It would be deadlock, if sock_queue_rcv_skb is used
- with socket lock! We assume that users of this
- function are lock free.
- */
- err = sk_filter(sk, skb, 1);
- if (err)
- goto out;
-
- skb->dev = NULL;
- skb_set_owner_r(skb, sk);
-
- /* Cache the SKB length before we tack it onto the receive
- * queue. Once it is added it no longer belongs to us and
- * may be freed by other threads of control pulling packets
- * from the queue.
- */
- skb_len = skb->len;
-
- skb_queue_tail(&sk->sk_receive_queue, skb);
-
- if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk, skb_len);
-out:
- return err;
-}
+extern int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
{
diff -urpN linux-2.6.16.org/net/core/sock.c linux-2.6.16.deinline/net/core/sock.c
--- linux-2.6.16.org/net/core/sock.c Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline/net/core/sock.c Mon Mar 27 09:45:09 2006
@@ -187,6 +187,99 @@ static void sock_disable_timestamp(struc
}
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+{
+ int err = 0;
+ int skb_len;
+
+ /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
+ number of warnings when compiling with -W --ANK
+ */
+ if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
+ (unsigned)sk->sk_rcvbuf) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ /* It would be deadlock, if sock_queue_rcv_skb is used
+ with socket lock! We assume that users of this
+ function are lock free.
+ */
+ err = sk_filter(sk, skb, 1);
+ if (err)
+ goto out;
+
+ skb->dev = NULL;
+ skb_set_owner_r(skb, sk);
+
+ /* Cache the SKB length before we tack it onto the receive
+ * queue. Once it is added it no longer belongs to us and
+ * may be freed by other threads of control pulling packets
+ * from the queue.
+ */
+ skb_len = skb->len;
+
+ skb_queue_tail(&sk->sk_receive_queue, skb);
+
+ if (!sock_flag(sk, SOCK_DEAD))
+ sk->sk_data_ready(sk, skb_len);
+out:
+ return err;
+}
+EXPORT_SYMBOL(sock_queue_rcv_skb);
+
+int sk_receive_skb(struct sock *sk, struct sk_buff *skb)
+{
+ int rc = NET_RX_SUCCESS;
+
+ if (sk_filter(sk, skb, 0))
+ goto discard_and_relse;
+
+ skb->dev = NULL;
+
+ bh_lock_sock(sk);
+ if (!sock_owned_by_user(sk))
+ rc = sk->sk_backlog_rcv(sk, skb);
+ else
+ sk_add_backlog(sk, skb);
+ bh_unlock_sock(sk);
+out:
+ sock_put(sk);
+ return rc;
+discard_and_relse:
+ kfree_skb(skb);
+ goto out;
+}
+EXPORT_SYMBOL(sk_receive_skb);
+
+struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie)
+{
+ struct dst_entry *dst = sk->sk_dst_cache;
+
+ if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) {
+ sk->sk_dst_cache = NULL;
+ dst_release(dst);
+ return NULL;
+ }
+
+ return dst;
+}
+EXPORT_SYMBOL(__sk_dst_check);
+
+struct dst_entry *sk_dst_check(struct sock *sk, u32 cookie)
+{
+ struct dst_entry *dst = sk_dst_get(sk);
+
+ if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) {
+ sk_dst_reset(sk);
+ dst_release(dst);
+ return NULL;
+ }
+
+ return dst;
+}
+EXPORT_SYMBOL(sk_dst_check);
+
/*
* This is meant for all protocols to use and covers goings on
* at the socket level. Everything here is generic.
^ permalink raw reply
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
From: Martin Michlmayr @ 2006-03-27 7:01 UTC (permalink / raw)
To: P. Horton
Cc: Geert Uytterhoeven, netdev, Linux/MIPS Development,
Francois Romieu
In-Reply-To: <20060309224456.GB9103@electric-eye.fr.zoreil.com>
* Francois Romieu <romieu@fr.zoreil.com> [2006-03-09 23:44]:
> > So when compiling for Cobalt, we work around the hardware bug, while for other
> > platforms, we just disable MWI?
> >
> > Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
> > work around the bug?
>
> Of course it is possible but it is not the same semantic as the initial
> patch (not that I know if it is right or not).
>
> So:
> - does the issue exist beyond Cobalt hosts ?
> - is the fix Cobalt-only ?
I don't think anyone has replied to this message yet. My
understanding is that it's not Cobalt only but a problem in a specific
revision of the chip, which the Cobalt happens to use. However, I'd
be glad if somone else could comment. Peter, you read the errata
right?
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: [2.6 patch] net: drop duplicate assignment in request_sock
From: David S. Miller @ 2006-03-27 1:39 UTC (permalink / raw)
To: bunk; +Cc: akpm, nkiesel, acme, linux-kernel, netdev
In-Reply-To: <20060326122410.GG4053@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 26 Mar 2006 14:24:10 +0200
> From: Norbert Kiesel <nkiesel@tbdnetworks.com>
>
> Just noticed that request_sock.[ch] contain a useless assignment of
> rskq_accept_head to itself. I assume this is a typo and the 2nd one
> was supposed to be _tail. However, setting _tail to NULL is not
> needed, so the patch below just drops the 2nd assignment.
>
> Signed-Off-By: Norbert Kiesel <nkiesel@tbdnetworks.com>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Michael Ellerman @ 2006-03-27 1:11 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc64-dev, netdev
In-Reply-To: <44074A22.8060705@us.ibm.com>
On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> From: Michael Ellerman <michael@ellerman.id.au>
>
> After a kexec the veth driver will fail when trying to register with the
> Hypervisor because the previous kernel has not unregistered.
>
> So if the registration fails, we unregister and then try again.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Acked-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Santiago Leon <santil@us.ibm.com>
> ---
>
> drivers/net/ibmveth.c | 32 ++++++++++++++++++++++++++------
> 1 files changed, 26 insertions(+), 6 deletions(-)
Looks like this hit the floor. Any chance of getting it into to 2.6.17
Jeff? AFAICT it should still apply cleanly.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
^ permalink raw reply
* Re: [Patch 8/9] generic netlink utility functions
From: jamal @ 2006-03-26 17:06 UTC (permalink / raw)
To: balbir; +Cc: Shailabh Nagar, linux-kernel, netdev
In-Reply-To: <20060326164434.GC13362@in.ibm.com>
On Sun, 2006-26-03 at 22:14 +0530, Balbir Singh wrote:
> Jamal,
>
> Does the implementation of these utilities look ok? We use genlmsg_data()
> in the delay accounting code but not genlmsg_len(), hence it might not
> be very well tested (just reviewed).
>
They look fine to me - please resubmit and CC Thomas Graf in case he
sees it different.
cheers,
jamal
^ permalink raw reply
* Re: [Patch 8/9] generic netlink utility functions
From: Balbir Singh @ 2006-03-26 16:44 UTC (permalink / raw)
To: Shailabh Nagar; +Cc: linux-kernel, netdev, Jamal
In-Reply-To: <1142297705.5858.28.camel@elinux04.optonline.net>
On Mon, Mar 13, 2006 at 07:55:05PM -0500, Shailabh Nagar wrote:
> genetlink-utils.patch
>
> Two utilities for simplifying usage of NETLINK_GENERIC
> interface.
>
> Signed-off-by: Balbir Singh <balbir@in.ibm.com>
> Signed-off-by: Shailabh Nagar <nagar@watson.ibm.com>
>
> include/net/genetlink.h | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+)
>
> Index: linux-2.6.16-rc5/include/net/genetlink.h
> ===================================================================
> --- linux-2.6.16-rc5.orig/include/net/genetlink.h 2006-03-11 07:41:32.000000000 -0500
> +++ linux-2.6.16-rc5/include/net/genetlink.h 2006-03-11 07:41:41.000000000 -0500
> @@ -150,4 +150,24 @@ static inline int genlmsg_unicast(struct
> return nlmsg_unicast(genl_sock, skb, pid);
> }
>
> +/**
> + * gennlmsg_data - head of message payload
> + * @gnlh: genetlink messsage header
> + */
> +static inline void *genlmsg_data(const struct genlmsghdr *gnlh)
> +{
> + return ((unsigned char *) gnlh + GENL_HDRLEN);
> +}
> +
> +/**
> + * genlmsg_len - length of message payload
> + * @gnlh: genetlink message header
> + */
> +static inline int genlmsg_len(const struct genlmsghdr *gnlh)
> +{
> + struct nlmsghdr *nlh = (struct nlmsghdr *)((unsigned char *)gnlh -
> + NLMSG_HDRLEN);
> + return (nlh->nlmsg_len - GENL_HDRLEN - NLMSG_HDRLEN);
> +}
> +
> #endif /* __NET_GENERIC_NETLINK_H */
>
>
Jamal,
Does the implementation of these utilities look ok? We use genlmsg_data()
in the delay accounting code but not genlmsg_len(), hence it might not
be very well tested (just reviewed).
Thanks,
Balbir
^ permalink raw reply
* Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
From: Balbir Singh @ 2006-03-26 16:40 UTC (permalink / raw)
To: jamal; +Cc: Matt Helsley, Shailabh Nagar, linux-kernel, netdev
In-Reply-To: <1143381918.5184.52.camel@jzny2>
On Sun, Mar 26, 2006 at 09:05:18AM -0500, jamal wrote:
> On Sat, 2006-25-03 at 23:52 +0530, Balbir Singh wrote:
>
>
> > No, we cannot have both passed. If we pass both a PID and a TGID and
> > then the code returns just the stats for the PID.
> >
>
> ok, that clears it then; i think you are ready to go.
Cool! Thanks for all your help and review.
>
> > >
> > > Also in regards to the nesting, isnt there a need for nla_nest_cancel in
> > > case of failures to add TLVs?
> > >
> >
> > I thought about it, but when I looked at the code of genlmsg_cancel()
> > and nla_nest_cancel(). It seemed that genlmsg_cancel() should
> > suffice.
> >
>
> If your policy is to never send a message if anything fails, then you
> are fine.
>
> What would be really useful now that you understand this, is if you can
> help extending/cleaning the document i sent you. Or send me a table of
> contents of how it would have flowed better for you.
I will start looking at the document and see what changes can be made.
I will try and update the document from a genetlink programmers perspective
i.e. things to know, avoid, etc.
>
> cheers,
> jamal
>
>
Thanks,
Balbir
^ permalink raw reply
* Re: [2.6 patch] make UNIX a bool
From: Jan-Benedict Glaw @ 2006-03-26 15:20 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Olaf Hering, Andrew Morton, netdev, linux-kernel
In-Reply-To: <20060325194739.GS4053@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
On Sat, 2006-03-25 20:47:39 +0100, Adrian Bunk <bunk@stusta.de> wrote:
> On Sat, Feb 25, 2006 at 11:46:31PM +0100, Olaf Hering wrote:
> > On Sat, Feb 25, Adrian Bunk wrote:
> > > CONFIG_UNIX=m doesn't make much sense.
> >
> > There is likely more code to support a modular unix.ko, this has to go
> > as well.
>
> Sounds resonable, updated patch below.
Thanks for the patch. I'll save it somewhere to have it handy for
"patch -R" use IFF it makes its ways into Linus's repo.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
From: jamal @ 2006-03-26 14:05 UTC (permalink / raw)
To: balbir; +Cc: Matt Helsley, Shailabh Nagar, linux-kernel, netdev
In-Reply-To: <661de9470603251022w7f8991e9g73d70a65f5d475ea@mail.gmail.com>
On Sat, 2006-25-03 at 23:52 +0530, Balbir Singh wrote:
> No, we cannot have both passed. If we pass both a PID and a TGID and
> then the code returns just the stats for the PID.
>
ok, that clears it then; i think you are ready to go.
> >
> > Also in regards to the nesting, isnt there a need for nla_nest_cancel in
> > case of failures to add TLVs?
> >
>
> I thought about it, but when I looked at the code of genlmsg_cancel()
> and nla_nest_cancel(). It seemed that genlmsg_cancel() should
> suffice.
>
If your policy is to never send a message if anything fails, then you
are fine.
What would be really useful now that you understand this, is if you can
help extending/cleaning the document i sent you. Or send me a table of
contents of how it would have flowed better for you.
cheers,
jamal
^ permalink raw reply
* [2.6 patch] net: drop duplicate assignment in request_sock
From: Adrian Bunk @ 2006-03-26 12:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Norbert Kiesel, acme, linux-kernel, netdev
From: Norbert Kiesel <nkiesel@tbdnetworks.com>
Just noticed that request_sock.[ch] contain a useless assignment of
rskq_accept_head to itself. I assume this is a typo and the 2nd one
was supposed to be _tail. However, setting _tail to NULL is not
needed, so the patch below just drops the 2nd assignment.
Signed-Off-By: Norbert Kiesel <nkiesel@tbdnetworks.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was sent by Norbert Kiesel on:
- 5 Mar 2006
diff -ru a/include/net/request_sock.h b/include/net/request_sock.h
--- a/include/net/request_sock.h 2005-10-28 15:44:45.000000000 -0700
+++ b/include/net/request_sock.h 2006-03-05 15:22:33.000000000 -0800
@@ -145,7 +145,7 @@
{
struct request_sock *req = queue->rskq_accept_head;
- queue->rskq_accept_head = queue->rskq_accept_head = NULL;
+ queue->rskq_accept_head = NULL;
return req;
}
diff -ru a/net/core/request_sock.c b/net/core/request_sock.c
--- a/net/core/request_sock.c 2006-03-05 14:40:50.000000000 -0800
+++ b/net/core/request_sock.c 2006-03-05 15:23:11.000000000 -0800
@@ -51,7 +51,7 @@
get_random_bytes(&lopt->hash_rnd, sizeof(lopt->hash_rnd));
rwlock_init(&queue->syn_wait_lock);
- queue->rskq_accept_head = queue->rskq_accept_head = NULL;
+ queue->rskq_accept_head = NULL;
lopt->nr_table_entries = nr_table_entries;
write_lock_bh(&queue->syn_wait_lock);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox