Re: [patch 2/5] s2io driver updates
Ananda Raju <[EMAIL PROTECTED]> :
[...]
> Signed-off-by: Ananda Raju <[EMAIL PROTECTED]>
> ---
> diff -upNr perf_fixes/drivers/net/s2io.c dmesg_param_fixes/drivers/net/s2io.c
> --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.0 -0700
> +++ dmesg_param_fixes/drivers/net/s2io.c 2006-04-13 09:08:22.0
> -0700
[...]
> @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> return ret;
> }
>
> +static void s2io_vpd_read(nic_t *nic)
> +{
> + u8 vpd_data[256],data;
You may consider removing vpd_data from the stack and kmallocing it.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] ixgb: Fix compilation errors by initializing variables
Jeff Kirsher <[EMAIL PROTECTED]> :
> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
> index cfd67d8..0b9481a 100644
> --- a/drivers/net/ixgb/ixgb_main.c
> +++ b/drivers/net/ixgb/ixgb_main.c
[...]
> @@ -346,7 +346,7 @@ ixgb_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> {
> struct net_device *netdev = NULL;
> - struct ixgb_adapter *adapter;
> + struct ixgb_adapter *adapter = NULL;
Afaiks the warning/error from the compiler is bogus.
netdev initialization is useless as well.
Are we supposed to bloat the kernel code on a large scale just
to please a compiler which emits bogus warning or is the option
left to the maintainer ?
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] ixgb: Fix hard coded numbers
Jeff Kirsher <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
> index e8d83de..978be30 100644
> --- a/drivers/net/ixgb/ixgb_ethtool.c
> +++ b/drivers/net/ixgb/ixgb_ethtool.c
[...]
> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
> index 6f8fd6f..f468d5d 100644
> --- a/drivers/net/ixgb/ixgb_main.c
> +++ b/drivers/net/ixgb/ixgb_main.c
> @@ -1227,11 +1227,11 @@ ixgb_tso(struct ixgb_adapter *adapter, s
> if(++i == adapter->tx_ring.count) i = 0;
> adapter->tx_ring.next_to_use = i;
>
> - return 1;
> + return TRUE;
> }
> #endif
>
> - return 0;
> + return FALSE;
> }
Grmbl... TRUE/FALSE
More importantly, it seems bogus. See below:
drivers/net/ixgb/ixgb_main.c::ixgb_xmit_frame
[...]
tso = ixgb_tso(adapter, skb);
if (tso < 0) {
^^^
dev_kfree_skb_any(skb);
return N
[...]
> @@ -1413,7 +1413,7 @@ ixgb_xmit_frame(struct sk_buff *skb, str
> if(unlikely(IXGB_DESC_UNUSED(&adapter->tx_ring) < DESC_NEEDED)) {
> netif_stop_queue(netdev);
> spin_unlock_irqrestore(&adapter->tx_lock, flags);
> - return 1;
> + return NETDEV_TX_BUSY;
> }
It is considered a bug. You can check for this situation on the current
skb but the driver should check if there is enough room for the *next*
packet before it leaves ixgb_xmit_frame().
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] ixgb: Fix the use of dprintk rather than printk
Jeff Kirsher <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
> index c83271b..a696c33 100644
> --- a/drivers/net/ixgb/ixgb.h
> +++ b/drivers/net/ixgb/ixgb.h
[...]
> @@ -192,6 +197,7 @@ struct ixgb_adapter {
>
> /* structs defined in ixgb_hw.h */
> struct ixgb_hw hw;
> + u16 msg_enable;
> struct ixgb_hw_stats stats;
> #ifdef CONFIG_PCI_MSI
> boolean_t have_msi;
> diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
> index d38ade5..e8d83de 100644
> --- a/drivers/net/ixgb/ixgb_ethtool.c
> +++ b/drivers/net/ixgb/ixgb_ethtool.c
> @@ -251,6 +251,20 @@ ixgb_set_tso(struct net_device *netdev,
> }
> #endif /* NETIF_F_TSO */
>
> +static uint32_t
> +ixgb_get_msglevel(struct net_device *netdev)
> +{
> + struct ixgb_adapter *adapter = netdev->priv;
> + return adapter->msg_enable;
> +}
> +
> +static void
> +ixgb_set_msglevel(struct net_device *netdev, uint32_t data)
> +{
> + struct ixgb_adapter *adapter = netdev->priv;
> + adapter->msg_enable = data;
> +}
> +
Minor nits:
- you may consider removing the u{8/16/32} in drivers/net/ixgb
for consistency sake in a different patch (there is a strong
majority of uint_something in the driver).
- s/netdev->priv/netdev_priv(netdev)/ ?
[...]
> @@ -486,8 +495,7 @@ ixgb_probe(struct pci_dev *pdev,
> netif_carrier_off(netdev);
> netif_stop_queue(netdev);
>
> - printk(KERN_INFO "%s: Intel(R) PRO/10GbE Network Connection\n",
> -netdev->name);
> + DPRINTK(PROBE, INFO, "Intel(R) PRO/10GbE Network Connection\n");
It could probably be factored out with ixgb_driver_string.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
Running this on my alpha gives (gcc 4.0.2):
3000
0123456A01234567
Andrew Morton wrote:
>> Because networking does read/write "short" fields in various packet
>> header structures. Results are illustrated in a following example:
>>
>> char foo[] __attribute__((aligned(8))) = "0123456701234567";
>>
>> int main()
>> {
>> short *bar = (short *)&foo[7];
>> printf("%04x\n", *bar); /* 3037 */
>> *bar = 0x4241; /* "AB" */
>> printf("%s\n", foo);
>> return 0;
>> }
>>
>> 0037
>> ^^
>> 0123456A01234567
>> ^
>> Misalignment by two bytes for ints and longs is often unavoidable in
>> networking and we can cope with it, but there is no excuse of 1-byte
>> misalignment.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: add to MAINTAINERS
If someone wants to be added/removed, please reply to this mail. Otherwise, John/Andrew/someone please apply. -- Index: linux-2.6/MAINTAINERS === --- linux-2.6.orig/MAINTAINERS 2006-04-20 18:14:44.0 +0200 +++ linux-2.6/MAINTAINERS 2006-04-22 17:27:25.0 +0200 @@ -421,6 +421,14 @@ W: http://www.baycom.org/~tom/ham/ham.html S: Maintained +BCM43XX WIRELESS DRIVER +P: Michael Buesch +M: [EMAIL PROTECTED] +P: Stefano Brivio +M: [EMAIL PROTECTED] +W: http://bcm43xx.berlios.de/ +S: Maintained + BEFS FILE SYSTEM P: Sergey S. Kostyliov M: [EMAIL PROTECTED] -- Greetings Michael. pgpnRg7kuHhhI.pgp Description: PGP signature
[PATCH TESTING] bcm43xx PIO mode
Hi,
Here is a patch to get PIO mode working in
the bcm43xx driver for cards that support it.
Supporting cards are all the "older" ones like 4306
(Apple Airport Extreme).
Please test this patch on a little endian machine,
such as i386. This patch works on PPC, but I am
not 100% sure, if I got the endianess right.
So please someone test it for me.
I would like to get this into mainline kernel
before 2.6.17 (if it works correctly on LE), because
this could be used as a tempoary solution for
people with the >1G problem.
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
2006-04-11 06:26:46.0 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h 2006-04-22
16:47:51.0 +0200
@@ -213,6 +213,14 @@
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring)
{
}
+static inline
+void bcm43xx_dma_tx_suspend(struct bcm43xx_dmaring *ring)
+{
+}
+static inline
+void bcm43xx_dma_tx_resume(struct bcm43xx_dmaring *ring)
+{
+}
#endif /* CONFIG_BCM43XX_DMA */
#endif /* BCM43xx_DMA_H_ */
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
2006-04-11 06:26:46.0 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_pio.c 2006-04-22
16:48:23.0 +0200
@@ -27,6 +27,7 @@
#include "bcm43xx_pio.h"
#include "bcm43xx_main.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_power.h"
#include
@@ -44,10 +45,10 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
}
@@ -103,7 +104,7 @@
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
skb->data[skb->len - 1]);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI |
+ BCM43xx_PIO_TXCTL_WRITELO |
BCM43xx_PIO_TXCTL_COMPLETE);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
@@ -112,9 +113,10 @@
}
static u16 generate_cookie(struct bcm43xx_pioqueue *queue,
- int packetindex)
+ struct bcm43xx_pio_txpacket *packet)
{
u16 cookie = 0x;
+ int packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -135,6 +137,7 @@
default:
assert(0);
}
+ packetindex = pio_txpacket_getindex(packet);
assert(((u16)packetindex & 0xF000) == 0x);
cookie |= (u16)packetindex;
@@ -184,7 +187,7 @@
bcm43xx_generate_txhdr(queue->bcm,
&txhdr, skb->data, skb->len,
(packet->xmitted_frags == 0),
- generate_cookie(queue,
pio_txpacket_getindex(packet)));
+ generate_cookie(queue, packet));
tx_start(queue);
octets = skb->len + sizeof(txhdr);
@@ -241,7 +244,7 @@
queue->tx_devq_packets++;
queue->tx_devq_used += octets;
- assert(packet->xmitted_frags <= packet->txb->nr_frags);
+ assert(packet->xmitted_frags < packet->txb->nr_frags);
packet->xmitted_frags++;
packet->xmitted_octets += octets;
}
@@ -257,8 +260,14 @@
unsigned long flags;
struct bcm43xx_pio_txpacket *packet, *tmp_packet;
int err;
+ u16 txctl;
bcm43xx_lock_mmio(bcm, flags);
+
+ txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
+ if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
+ return;
+
list_for_each_entry_safe(packet, tmp_packet, &queue->txqueue, list) {
assert(packet->xmitted_frags < packet->txb->nr_frags);
if (packet->xmitted_frags == 0) {
@@ -330,7 +339,7 @@
(unsigned long)queue);
value = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- value |= BCM43xx_SBF_XFER_REG_BYTESWAP;
+ value &= ~BCM43xx_SBF_XFER_REG_BYTESWAP;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value);
qsize = bcm43xx_read16(bcm, queue->mmio_base + BCM43xx_PIO_TXQBUFSIZE);
@@ -444,15 +453,10 @@
{
stru
Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> 05/10: [PATCH] Update truesize with the length of the packet for
>> packet split
>
> These 10 patches look OK, but since the current kernel version is
> 2.6.17-rc1, that means we are in "bug fix only" mode right now.
>
> Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
> for 2.6.18, or (b) let you split the submission into two parts, bug
> fixes only and everything else?
It turns out that the truesize patch is pretty important as otherwise
most of TCP receive socket buffer accounting falls apart. So it should
probably go into 2.6.17 and even 2.6.16-stable.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] ixgb: Add prefetch
Jeff Kirsher a écrit : - This patch is to improve performance by adding prefetch to the ixgb driver - Add driver comments Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- drivers/net/ixgb/ixgb_main.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c index 26cb0d5..98303cb 100644 --- a/drivers/net/ixgb/ixgb_main.c +++ b/drivers/net/ixgb/ixgb_main.c @@ -29,6 +29,13 @@ #include "ixgb.h" /* Change Log + * 1.0.104 10-Jan-2006 + * - fix for copybreak/recycle + * 1.0.103 Oct-3 + * - suck in some e1000 changes, including copybreak and LLTX + * - support for CX4 adapters + * 1.0.102 June-20-2005 + * - add a workaround for a hardware issue when using TSO * 1.0.96 04/19/05 * - Make needlessly global code static -- [EMAIL PROTECTED] * - ethtool cleanup -- [EMAIL PROTECTED] @@ -1916,7 +1923,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a skb = buffer_info->skb; buffer_info->skb = NULL; - prefetch(skb->data); + prefetch(skb->data - NET_IP_ALIGN); I doubt this change is usefull. skb->data and dkb->dta - NET_IP_ALIGN are on the same cache line. So prefetch(skb->data) is cheaper for he compiler and has the same effect on the memory prefetch that is eventually done by the cpu. if(++i == rx_ring->count) i = 0; next_rxd = IXGB_RX_DESC(*rx_ring, i); @@ -1929,6 +1936,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a next_buffer = &rx_ring->buffer_info[i]; next_skb = next_buffer->skb; prefetch(next_skb); + prefetch(next_skb->data - NET_IP_ALIGN); I doubt that next->skb_data is available for free just after a prefetch(next_skb). This second prefetch has a hidden cost : The memory location (&next_skb->data) must be in L1 cache. So basically the prefetch(next_skb) is useless... prefetch are not magic things. They have a cost (they increase the code size), and should be used carefully. Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote: > Going all the way to the socket is a large endeavor and will require a > lot of restructuring to do it right, so expect this to take on the > order of months. That's what you said about Niagara too :-) Good luck! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
Hi Jörn, On Saturday, 22. April 2006 13:48, Jörn Engel wrote: > Unless I completely misunderstand something, one of the main points of > the netchannels if to have *zero* fields written to by both producer > and consumer. Hmm, for me the main point was to keep the complete processing of a single packet within one CPU/Core where this is a non-issue. > Receiving and sending a lot can be expected to be the > common case, so taking a performance hit in this case is hardly a good > idea. There is no hit. If you receive/send in bursts you can simply aggregate them until a certain queueing threshold. The queue design outlined can split the queueing in reserve and commit stages, where the producer can be told how much in can produce and the consumer is told how much it can consume. Within their areas the producer and consumer can freely move around. So this is not exactly a queue, but a dynamic double buffer :-) So maybe doing queueing with the classic head/tail variant is better here, but the other variant might replace it without problems and allows for some nice improvements. Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH TESTING] bcm43xx PIO mode
On Saturday 22 April 2006 17:18, you wrote: > bcm43xx_lock_mmio(bcm, flags); > + > + txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL); > + if (txctl & BCM43xx_PIO_TXCTL_SUSPEND) > + return; Ah, and yes, I see the bug here. :) But that normally does not trigger anyway. So no problem for testing. And I forgot to say that PIO mode is enabled by module parameter pio=1 -- Greetings Michael. pgpPMEmAY7Xd6.pgp Description: PGP signature
Re: Van Jacobson's net channels and real-time
On Sat, 22 April 2006 15:29:58 +0200, Ingo Oeser wrote: > On Saturday, 22. April 2006 13:48, Jörn Engel wrote: > > Unless I completely misunderstand something, one of the main points of > > the netchannels if to have *zero* fields written to by both producer > > and consumer. > > Hmm, for me the main point was to keep the complete processing > of a single packet within one CPU/Core where this is a non-issue. That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. Jörn -- Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
On Fri, 21 April 2006 18:52:47 +0200, Ingo Oeser wrote:
> What about sth. like
>
> struct netchannel {
>/* This is only read/written by the writer (producer) */
>unsigned long write_ptr;
> struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
>
>/* This is modified by both */
> atomic_t filled_entries; /* cache_line_align this? */
>
>/* This is only read/written by the reader (consumer) */
>unsigned long read_ptr;
> }
>
> This would prevent this bug from the beginning and let us still use the
> full queue size.
>
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer. Receiving and sending a lot can be expected to be the
common case, so taking a performance hit in this case is hardly a good
idea.
I haven't looked at Davem's implementation at all, but Van simply
seperated fields in consumer-written and producer-written, with proper
alignment between them. Some consumer-written fields are also read by
the producer and vice versa. But none of this results in cacheline
pingpong.
If your description of the problem is correct, it should only mean
that the implementation has a problem, not the concept.
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/10] d80211: get rid of default management interface
On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote: > Default management interface (wlanXap) confuses users. It is only needed for > AP mode (and only until interfaces are converted to use native 802.11 > frames). Or when using user space MLME in client mode which is something that I just got working as far as scanning and association is concerned. In other words, wpa_supplicant will be needing this interface.. > This patch removes default management interface. When a new interface is > switched to AP mode, a management interface is created automatically. This > also fixes some problems with multiple AP interfaces - now you have > different management interface for each AP interface. That sounds like something that could break multi-BSSID/SSID aware hostapd. Are you saying that there would be new wlanXap like interface for each BSS/VLAN interface? What are the problems this is fixing with multiple AP interfaces? So far, hostapd has been responsible for receiving all management from a single interface and then internally decide which BSS/multi-SSID entry to use for each. I would assume that hostapd could be changed to process frames from multiple interfaces (at least if this is only for multi-BSSID, not for multi-SSID/VLAN case). There may be some special cases, where it would be easier to just be able to use one interface. Likewise, I would expect single interface to be closer to a design that would be using netlink for getting management frames into user space. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 4/8] Utilities for genetlink usage
genetlink-utils.patch
Two utilities for simplifying usage of NETLINK_GENERIC
interface.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Signed-off-by: Shailabh Nagar <[EMAIL PROTECTED]>
include/net/genetlink.h | 20
1 files changed, 20 insertions(+)
Index: linux-2.6.17-rc1/include/net/genetlink.h
===
--- linux-2.6.17-rc1.orig/include/net/genetlink.h 2006-04-21
19:39:29.0 -0400
+++ linux-2.6.17-rc1/include/net/genetlink.h2006-04-21 20:29:19.0
-0400
@@ -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 */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: sky2 driver network freeze while transfering data
Begin forwarded message: Date: Sat, 22 Apr 2006 12:45:44 +0200 From: thomas klein <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Subject: sky2 driver network freeze while transfering data [EMAIL PROTECTED]:~/kernel/linux-2.6.16.9$ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006 i686 GNU/Linux Gnu C 4.0.3 Gnu make 3.81beta4 binutils 2.16.91 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 jfsutils 1.1.8 reiserfsprogs 3.6.19 reiser4progs 1.0.5 xfsprogs 2.7.7 pcmcia-cs 3.2.8 Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.6 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.93 udev [EMAIL PROTECTED]:~/kernel/linux-2.6.16.9$ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux archon 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006 i686 GNU/Linux Gnu C 4.0.3 Gnu make 3.81beta4 binutils 2.16.91 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 jfsutils 1.1.8 reiserfsprogs 3.6.19 reiser4progs 1.0.5 xfsprogs 2.7.7 pcmcia-cs 3.2.8 Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.6 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.93 udev 079 Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi speedstep_centrino cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative video tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix generic thermal processor fan capability commoncap vga16fb vgastate fbcon tileblit font bitblit softcursor Modules Loaded binfmt_misc rfcomm l2cap bluetooth sonypi speedstep_centrino cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative video tc1100_wmi sony_acpi pcc_acpi hotkey dev_acpi container button acpi_sbs battery ac i2c_acpi_ec ipv6 dm_mod af_packet md_mod sr_mod sbp2 parport_pc lp parport pcmcia joydev yenta_socket rsrc_nonstatic ohci1394 sky2 pcmcia_core ieee1394 nvidia i2c_core rtc psmouse serio_raw snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug intel_agp agpgart tsdev evdev sg usbhid ext3 jbd ide_generic ehci_hcd uhci_hcd usbcore sd_mod ata_piix libata scsi_mod ide_cd cdrom piix generic thermal processor fan capability commoncap vga16fb vgastate fbcon tileblit font bitblit softcursor This is the stock kernel I'm using... I tried the latest 2.6.16.9, the problem was the same. Problem : :07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 15) I can browse the web, check emails etc... but, If I try some rsync from my old laptop (to backup my stuff) the network freeze after 1 or 2minutes. the bug is reproductible. I don't have logs each time, but, sometimes I got this Apr 15 11:35:42 archon kernel: [4297572.802000] NETDEV WATCHDOG: eth0: transmit timed out Apr 15 11:35:42 archon kernel: [4297572.802000] sky2 hardware hung? flushing same freeze with the 2.6.16.9 thanks in advance, thomas. PS : I didn't subscribe any linux ml, can I see any progress on this report somewhere ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
On Saturday, 22. April 2006 15:49, Jörn Engel wrote: > That was another main point, yes. And the endpoints should be as > little burden on the bottlenecks as possible. One bottleneck is the > receive interrupt, which shouldn't wait for cachelines from other cpus > too much. Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. In the meantime I would reduce the effects with only committing on full buffer or on leaving the interrupt handler. This would be ok, because here you have to wakeup the process anyway on full buffer and if it slept because of empty buffer. You loose only, if your application didn't sleep yet and you need to leave the interrupt handler because there is no work anymore. In this case the atomic_add would be significant. All this is quite similiar to now we do page_vec stuff in mm/ already. Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Is there any news about this issue?
Sorry for the delay, I've been travelling.
The fact that tcpdump with "host 172.16.0.138" does not fix it tells
us that this is related to the NAT that you're doing to the 172.16
side of the network.
Looking at your packet dump your setup is definitely suboptimal in
that correct MTU information is not being provided to either side
of the connection.
The result is that the 10.16 end is sending fragments which have to
be reassembled at mimosa before immediately getting refragmented on
its way to pleiadi.
So if it was my network this would be the first issue I'd try to
address, possibly through MSS clamping.
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
So I would like your help in tracking that down before you fix your
network properly.
For a start could you please send me the complete kern.log messages
on mimosa from boot time to the point after a slow connection has
occured. I'd also like to see /proc/net/snmp at that point.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
<[EMAIL PROTECTED]> wrote:
>
> And the output in the kernel ring buffer is:
> dmesg | grep xmit
> ei_start_xmit(): skb->data unaligned fc0019be55d5 align to
> fc001ef37620
> length 60
Very weird. The length seems to indicate that this packet went through
skb_padto. However, I can't see how skb_padto can produce an unaligned
skb if the input was aligned (the input coming out of TCP should definitely
be aligned).
Can you please put some printks in to find out if
1) skb_padto is being called.
2) Is the input to skb_padto aligned?
> Here some stack traces with BUG_ON/ WARN_ON added by me in more places to
> trace
> down the problem:
> Kernel bug at net/ipv4/ip_output.c:297
> cc1(2841): Kernel Bug 1
> pc = [] ra = [] ps = Not tainted
> pc is at ip_queue_xmit+0x59c/0x690
> ra is at tcp_transmit_skb+0x588/0xbb0
This is pretty meaningless if you don't show us the check that you added
to produce this.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bug 6421] New: kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
On Sun, Apr 23, 2006 at 03:43:22PM +1000, Herbert Xu wrote:
>
> Can you please put some printks in to find out if
>
> 1) skb_padto is being called.
> 2) Is the input to skb_padto aligned?
I'd also help if you could print out the contents of the packet itself.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
From: Ingo Oeser <[EMAIL PROTECTED]> Date: Sun, 23 Apr 2006 02:05:32 +0200 > On Saturday, 22. April 2006 15:49, Jörn Engel wrote: > > That was another main point, yes. And the endpoints should be as > > little burden on the bottlenecks as possible. One bottleneck is the > > receive interrupt, which shouldn't wait for cachelines from other cpus > > too much. > > Thats right. This will be made a non issue with early demuxing > on the NIC and MSI (or was it MSI-X?) which will select > the right CPU based on hardware channels. It is not clear that MSI'ing the RX interrupt to multiple cpus is the answer. Consider the fact that by doing so you're reducing the amount of batch work each interrupt does by a factor N. One of the biggest gains of NAPI btw is that it batches patcket receive, if you don't believe the benefits of this put a simply cycle counter sample around netif_receive_skb() calls, and note the difference between the first packet processed and subsequent ones, it's several orders of magnitude faster to process subsequent packets within a batch. I've done this before on tg3 with sparc64 and posted the numbers on netdev about a year or so ago. If you are doing something like netchannels, it helps to batch so that the demuxing table stays hot in the cpu cache. There is even talk of dedicating a thread on enormously multi- threaded cpus just to the NIC hardware interrupt, so it could net channel to the socket processes running on the other strands. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
From: Jörn Engel <[EMAIL PROTECTED]> Date: Sat, 22 Apr 2006 13:48:46 +0200 > Unless I completely misunderstand something, one of the main points of > the netchannels if to have *zero* fields written to by both producer > and consumer. Receiving and sending a lot can be expected to be the > common case, so taking a performance hit in this case is hardly a good > idea. That's absolutely correct, this is absolutely critical to the implementation. If you're doing any atomic operations, or any write operations by both consumer and producer to the same cacheline, you've broken things :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
From: bert hubert <[EMAIL PROTECTED]> Date: Sat, 22 Apr 2006 21:30:24 +0200 > On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote: > > Going all the way to the socket is a large endeavor and will require a > > lot of restructuring to do it right, so expect this to take on the > > order of months. > > That's what you said about Niagara too :-) I'm just trying to keep the expectations low so it's easier to exceed them :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
From: Ingo Oeser <[EMAIL PROTECTED]> Date: Sat, 22 Apr 2006 15:29:58 +0200 > On Saturday, 22. April 2006 13:48, Jörn Engel wrote: > > Unless I completely misunderstand something, one of the main points of > > the netchannels if to have *zero* fields written to by both producer > > and consumer. > > Hmm, for me the main point was to keep the complete processing > of a single packet within one CPU/Core where this is a non-issue. Both are the important issues. You move the bulk of the packet processing work to the end cores of the system, yes. But you do so with an enormously SMP friendly queue data structure so that it does not matter at all that the packet is received on one cpu, yet processed in socket context on another. If you elide either part of the implementation, you miss the entire point of net channels. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sat, 22 Apr 2006 15:22:54 +1000 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >> 05/10: [PATCH] Update truesize with the length of the packet for > >> packet split > > > > These 10 patches look OK, but since the current kernel version is > > 2.6.17-rc1, that means we are in "bug fix only" mode right now. > > > > Should I (a) apply these all to netdev2-.6.git#upstream, queueing them > > for 2.6.18, or (b) let you split the submission into two parts, bug > > fixes only and everything else? > > It turns out that the truesize patch is pretty important as otherwise > most of TCP receive socket buffer accounting falls apart. So it should > probably go into 2.6.17 and even 2.6.16-stable. I totally agree. Jeff please try to get at least this skb->truesize fix queued to both -stable and current 2.6.x, it's really needed and important for proper socket memory accounting on receive with e1000. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Van Jacobson's net channels and real-time
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Fri, 21 Apr 2006 18:52:47 +0200
> nice to see you getting started with it.
Thanks for reviewing.
> I'm not sure about the queue logic there.
>
> 1867 /* Caller must have exclusive producer access to the netchannel. */
> 1868 int netchannel_enqueue(struct netchannel *np, struct
> netchannel_buftrailer *bp)
> 1869 {
> 1870 unsigned long tail;
> 1871
> 1872 tail = np->netchan_tail;
> 1873 if (tail == np->netchan_head)
> 1874 return -ENOMEM;
>
> This looks wrong, since empty and full are the same condition in your
> case.
Thanks, that's obviously wrong. I'll try to fix this up.
> What about sth. like
>
> struct netchannel {
>/* This is only read/written by the writer (producer) */
>unsigned long write_ptr;
> struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
>
>/* This is modified by both */
> atomic_t filled_entries; /* cache_line_align this? */
>
>/* This is only read/written by the reader (consumer) */
>unsigned long read_ptr;
> }
As stated elsewhere, if you add atomic operations you break the entire
idea of net channels. They are meant to be SMP efficient data structures
where the producer has one cache line that only it dirties and the
consumer has one cache line that likewise only it dirties.
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
Cacheline bouncing is the core issue being addressed by this
data structure, so we really can't consider your idea seriously.
I've just got an off-by-one error, no need to wreck the entire
data structure just to solve that :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
