Re: 3c985 (aka acenic) gigabit support broken in test9pre7?
"Andrew" == Andrew Morton [EMAIL PROTECTED] writes: Andrew The module_init() and module_exit() are inside `#ifdef Andrew MODULE'. So if the driver is statically linked it doesn't Andrew register any initcalls. It won't do anything. ARGH I keep getting those ones wrong ;-( Thanks Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: Alan> unsigned is always explicitly integer. >> And recent gcc's complain over it. Alan> So file a gcc bug ? Hmmm and it doesn't seem to moan over it anymore, highly embarrassing ;-( Sorry Aris. I remember Andreas changed some of these in I think the file system code about 1.5 years ago for that reason though. Oh well, unsigned without the int it still ugly of course ;-) Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: Alan> unsigned is always explicitly integer. >> And recent gcc's complain over it. Alan> So file a gcc bug ? Ok, I got it now - I confused 'unsigned foo' with 'static foo' the latter being moaned about. Sorry about the confusion. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: aris> + unsigned xmt_lower_limit_reg; + unsigned xmt_upper_limit_reg; aris> + unsigned eeprom_reg; }; >> Please don't use unsigned without specifying the size, use either >> unsigned int or unsigned long. Alan> unsigned is always explicitly integer. And recent gcc's complain over it. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
> "aris" == aris <[EMAIL PROTECTED]> writes: aris> hi, misc fixes on eepro driver, please apply aris> @@ -212,6 +214,12 @@ aris> version of the 82595 chip. */ aris> int stepping; aris> spinlock_t lock; /* Serializing lock */ aris> + unsigned rcv_ram; aris> + unsigned rcv_start; aris> + unsigned xmt_bar; aris> + unsigned xmt_lower_limit_reg; aris> + unsigned xmt_upper_limit_reg; aris> + unsigned eeprom_reg; aris> }; Please don't use unsigned without specifying the size, use either unsigned int or unsigned long. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: the new VMt
>>>>> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: Ingo> On 26 Sep 2000, Jes Sorensen wrote: >> 9.5KB blocks is common for people running Gigabit Ethernet with >> Jumbo frames at least. Ingo> yep, although this is more of a Linux limitation, the cards Ingo> themselves are happy to DMA fragmented buffers as well. (sans Ingo> some small penalty per new fragment.) Hence the reason I have been pushing for the kiobufifying of the skbs ;-) It's even more important for HIPPI with the 65280 bytes MTU. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: the new VMt
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: Ingo> On Mon, 25 Sep 2000, Andrea Arcangeli wrote: >> > ie. 99.45% of all allocations are single-page! 0.50% is the 8kb >> >> You're right. That's why it's a waste to have so many order in the >> buddy allocator. [...] Ingo> yep, i agree. I'm not sure what the biggest allocation is, some Ingo> drivers might use megabytes or contiguous RAM? 9.5KB blocks is common for people running Gigabit Ethernet with Jumbo frames at least. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
"aris" == aris [EMAIL PROTECTED] writes: aris hi, misc fixes on eepro driver, please apply aris @@ -212,6 +214,12 @@ aris version of the 82595 chip. */ aris int stepping; aris spinlock_t lock; /* Serializing lock */ aris + unsigned rcv_ram; aris + unsigned rcv_start; aris + unsigned xmt_bar; aris + unsigned xmt_lower_limit_reg; aris + unsigned xmt_upper_limit_reg; aris + unsigned eeprom_reg; aris }; Please don't use unsigned without specifying the size, use either unsigned int or unsigned long. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
"Alan" == Alan Cox [EMAIL PROTECTED] writes: aris + unsigned xmt_lower_limit_reg; + unsigned xmt_upper_limit_reg; aris + unsigned eeprom_reg; }; Please don't use unsigned without specifying the size, use either unsigned int or unsigned long. Alan unsigned is always explicitly integer. And recent gcc's complain over it. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
"Alan" == Alan Cox [EMAIL PROTECTED] writes: Alan unsigned is always explicitly integer. And recent gcc's complain over it. Alan So file a gcc bug ? Ok, I got it now - I confused 'unsigned foo' with 'static foo' the latter being moaned about. Sorry about the confusion. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro 0.12c
"Alan" == Alan Cox [EMAIL PROTECTED] writes: Alan unsigned is always explicitly integer. And recent gcc's complain over it. Alan So file a gcc bug ? Hmmm and it doesn't seem to moan over it anymore, highly embarrassing ;-( Sorry Aris. I remember Andreas changed some of these in I think the file system code about 1.5 years ago for that reason though. Oh well, unsigned without the int it still ugly of course ;-) Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
acenic v0.47 update
Hi Linus
One of the two patches I sent you for the acenic driver got lost in
the 2.4.0-test8-something update. Here is an uptodate patch for
2.4.0-test9-beta2 which fixes a few more problems.
Jes
--- drivers/net/acenic.c-oldMon Sep 18 09:26:45 2000
+++ drivers/net/acenic.cMon Sep 18 11:06:48 2000
@@ -29,7 +29,16 @@
* infrastructure and Sparc support
* Pierrick Pinasseau (CERN): For lending me an Ultra 5 to test the
* driver under Linux/Sparc64
- * Matt Domsch <[EMAIL PROTECTED]>: Detect 1000baseT cards
+ * Matt Domsch <[EMAIL PROTECTED]>: Detect Alteon 1000baseT cards
+ * Chip Salzenberg <[EMAIL PROTECTED]>: Fix race condition between tx
+ * handler and close() cleanup.
+ * Ken Aaker <[EMAIL PROTECTED]>: Correct check for whether
+ * memory mapped IO is enabled to
+ * make the driver work on RS/6000.
+ * Takayoshi Kouchi <[EMAIL PROTECTED]>: Identifying problem
+ * where the driver would disable
+ * bus master mode if it had to disable
+ * write and invalidate.
*/
#include
@@ -83,8 +92,13 @@
#define PCI_VENDOR_ID_NETGEAR 0x1385
#define PCI_DEVICE_ID_NETGEAR_GA6200x620a
#endif
+#ifndef PCI_DEVICE_ID_NETGEAR_GA620T
+#define PCI_DEVICE_ID_NETGEAR_GA620T 0x630a
+#endif
+
/*
- * They used the DEC vendor ID by mistake
+ * Farallon used the DEC vendor ID by mistake and they seem not
+ * to care - stinky!
*/
#ifndef PCI_DEVICE_ID_FARALLON_PN9000SX
#define PCI_DEVICE_ID_FARALLON_PN9000SX0x1a
@@ -389,7 +403,7 @@
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
static const char __initdata *version =
- "acenic.c: v0.44 05/11/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
+ "acenic.c: v0.47 09/18/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
static struct net_device *root_dev = NULL;
@@ -429,7 +443,8 @@
!((pdev->vendor == PCI_VENDOR_ID_3COM) &&
(pdev->device == PCI_DEVICE_ID_3COM_3C985)) &&
!((pdev->vendor == PCI_VENDOR_ID_NETGEAR) &&
- (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620)) &&
+ ((pdev->device == PCI_DEVICE_ID_NETGEAR_GA620) ||
+ (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620T))) &&
/*
* Farallon used the DEC vendor ID on their cards by
* mistake for a while
@@ -477,10 +492,17 @@
printk(version);
}
+ /*
+* Enable master mode before we start playing with the
+* pci_command word since pci_set_master() will modify
+* it.
+*/
+ pci_set_master(pdev);
+
pci_read_config_word(pdev, PCI_COMMAND, >pci_command);
/* OpenFirmware on Mac's does not set this - DOH.. */
- if (!ap->pci_command & PCI_COMMAND_MEMORY) {
+ if (!(ap->pci_command & PCI_COMMAND_MEMORY)) {
printk(KERN_INFO "%s: Enabling PCI Memory Mapped "
"access - was not enabled by BIOS/Firmware\n",
dev->name);
@@ -498,8 +520,6 @@
ap->pci_latency);
}
- pci_set_master(pdev);
-
/*
* Remap the regs into kernel space - this is abuse of
* dev->base_addr since it was means for I/O port
@@ -606,9 +626,9 @@
MODULE_PARM(max_tx_desc, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i");
-
#endif
+
void __exit ace_module_cleanup(void)
{
struct ace_private *ap;
@@ -712,6 +732,7 @@
return status;
}
+
#ifdef MODULE
#if (LINUX_VERSION_CODE < 0x02032a)
int init_module(void)
@@ -730,6 +751,7 @@
#endif
#endif
+
static void ace_free_descriptors(struct net_device *dev)
{
struct ace_private *ap = dev->priv;
@@ -1994,18 +2016,34 @@
if (txcsm != idx) {
do {
struct sk_buff *skb;
- dma_addr_t mapping;
skb = ap->skb->tx_skbuff[idx].skb;
- mapping = ap->skb->tx_skbuff[idx].mapping;
+ /*
+* Race condition
Re: PROBLEM: umount report "busy" on r/o remount of root filesystem
> "Pavel" == pavelk <[EMAIL PROTECTED]> writes: Pavel> Umount (and mount on next line too) report "/: device is busy" Pavel> and the root filesystem stay not correctly unmounted. But when Pavel> i press magic key "u" (emergency remount), the filesystem is Pavel> correctly remounted. All other mounted filesystems are Pavel> correctly unmounted by "umount -a". This bug is present only on Pavel> my motherboard with SiS5513 chipset; on other motherboard with Pavel> VIA chipset and the totaly same linux it's all right. The Pavel> second thing is, that on kernels 2.2.X (up to 2.2.13, later Pavel> i've not tested) it's ok too. The version of mount has not any Pavel> influence. Pavel> hardware: Pentium 75, SiS chipset, 64MB RAM HDD WDC AC36400L Pavel> 6449MB, DMA disabled, PIO 4 Pavel> software: kernel 2.4.0-test7 gcc 2.95.2 binutils 2.10 mount Pavel> 2.10o glibc 2.1.3 2.2.13 and gcc-2.95.2 are not compatible, try with the correct compiler first. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
acenic v0.47 update
Hi Linus
One of the two patches I sent you for the acenic driver got lost in
the 2.4.0-test8-something update. Here is an uptodate patch for
2.4.0-test9-beta2 which fixes a few more problems.
Jes
--- drivers/net/acenic.c-oldMon Sep 18 09:26:45 2000
+++ drivers/net/acenic.cMon Sep 18 11:06:48 2000
@@ -29,7 +29,16 @@
* infrastructure and Sparc support
* Pierrick Pinasseau (CERN): For lending me an Ultra 5 to test the
* driver under Linux/Sparc64
- * Matt Domsch [EMAIL PROTECTED]: Detect 1000baseT cards
+ * Matt Domsch [EMAIL PROTECTED]: Detect Alteon 1000baseT cards
+ * Chip Salzenberg [EMAIL PROTECTED]: Fix race condition between tx
+ * handler and close() cleanup.
+ * Ken Aaker [EMAIL PROTECTED]: Correct check for whether
+ * memory mapped IO is enabled to
+ * make the driver work on RS/6000.
+ * Takayoshi Kouchi [EMAIL PROTECTED]: Identifying problem
+ * where the driver would disable
+ * bus master mode if it had to disable
+ * write and invalidate.
*/
#include linux/config.h
@@ -83,8 +92,13 @@
#define PCI_VENDOR_ID_NETGEAR 0x1385
#define PCI_DEVICE_ID_NETGEAR_GA6200x620a
#endif
+#ifndef PCI_DEVICE_ID_NETGEAR_GA620T
+#define PCI_DEVICE_ID_NETGEAR_GA620T 0x630a
+#endif
+
/*
- * They used the DEC vendor ID by mistake
+ * Farallon used the DEC vendor ID by mistake and they seem not
+ * to care - stinky!
*/
#ifndef PCI_DEVICE_ID_FARALLON_PN9000SX
#define PCI_DEVICE_ID_FARALLON_PN9000SX0x1a
@@ -389,7 +403,7 @@
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
static const char __initdata *version =
- "acenic.c: v0.44 05/11/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
+ "acenic.c: v0.47 09/18/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
static struct net_device *root_dev = NULL;
@@ -429,7 +443,8 @@
!((pdev-vendor == PCI_VENDOR_ID_3COM)
(pdev-device == PCI_DEVICE_ID_3COM_3C985))
!((pdev-vendor == PCI_VENDOR_ID_NETGEAR)
- (pdev-device == PCI_DEVICE_ID_NETGEAR_GA620))
+ ((pdev-device == PCI_DEVICE_ID_NETGEAR_GA620) ||
+ (pdev-device == PCI_DEVICE_ID_NETGEAR_GA620T)))
/*
* Farallon used the DEC vendor ID on their cards by
* mistake for a while
@@ -477,10 +492,17 @@
printk(version);
}
+ /*
+* Enable master mode before we start playing with the
+* pci_command word since pci_set_master() will modify
+* it.
+*/
+ pci_set_master(pdev);
+
pci_read_config_word(pdev, PCI_COMMAND, ap-pci_command);
/* OpenFirmware on Mac's does not set this - DOH.. */
- if (!ap-pci_command PCI_COMMAND_MEMORY) {
+ if (!(ap-pci_command PCI_COMMAND_MEMORY)) {
printk(KERN_INFO "%s: Enabling PCI Memory Mapped "
"access - was not enabled by BIOS/Firmware\n",
dev-name);
@@ -498,8 +520,6 @@
ap-pci_latency);
}
- pci_set_master(pdev);
-
/*
* Remap the regs into kernel space - this is abuse of
* dev-base_addr since it was means for I/O port
@@ -606,9 +626,9 @@
MODULE_PARM(max_tx_desc, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i");
-
#endif
+
void __exit ace_module_cleanup(void)
{
struct ace_private *ap;
@@ -712,6 +732,7 @@
return status;
}
+
#ifdef MODULE
#if (LINUX_VERSION_CODE 0x02032a)
int init_module(void)
@@ -730,6 +751,7 @@
#endif
#endif
+
static void ace_free_descriptors(struct net_device *dev)
{
struct ace_private *ap = dev-priv;
@@ -1994,18 +2016,34 @@
if (txcsm != idx) {
do {
struct sk_buff *skb;
- dma_addr_t mapping;
skb = ap-skb-tx_skbuff[idx].skb;
- mapping = ap-skb-tx_skbuff[idx].mapping;
+ /*
+* Race condition between the code cleaning
+* the tx queue in the interrupt handler and the
+* interface close,
+*
+
Re: Preallocated skb's?
> "jamal" == jamal <[EMAIL PROTECTED]> writes: jamal> The FF code of the tulip does have skb recycling code. And i jamal> belive Jes' acenic code does or did at some point. Robert jamal> Olson and I were thinking of taking out that code out of the jamal> tulip for reasons such as you talk about (and the thought maybe jamal> that the per-CPU slab might have obsoleted that jamal> requirement). We did some tests with 2.4.0-test7 and were jamal> suprised to observe that at high rate of input packets, it jamal> still made as a big a difference as 7000 packets per second ;-> jamal> i.e we got 7Kpps more by using skb recycling. I tried recycling in the acenic driver, but after adding Ingo's early per CPU slab caches I couldn't see any measurable performance gain from using recycling. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Preallocated skb's?
"jamal" == jamal [EMAIL PROTECTED] writes: jamal The FF code of the tulip does have skb recycling code. And i jamal belive Jes' acenic code does or did at some point. Robert jamal Olson and I were thinking of taking out that code out of the jamal tulip for reasons such as you talk about (and the thought maybe jamal that the per-CPU slab might have obsoleted that jamal requirement). We did some tests with 2.4.0-test7 and were jamal suprised to observe that at high rate of input packets, it jamal still made as a big a difference as 7000 packets per second ;- jamal i.e we got 7Kpps more by using skb recycling. I tried recycling in the acenic driver, but after adding Ingo's early per CPU slab caches I couldn't see any measurable performance gain from using recycling. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Whining about MIME formatted email
> "David" == David Ford <[EMAIL PROTECTED]> writes: David> C program instructions are in ASCII, data certainly isn't David> restricted to that. If you or your M*A can't or won't deal David> with anything but plain text, then filter it. Plain text is David> clearly in the minority of emails throughout the world and the David> people on LKML seem in general not to care about MIME and David> frequently use it. Let's end this offtopic thread please. Says the guy who puts his response in front of the quoted text which violates rfc1855 and adds a vcard you really expect people to take you serious? Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
>>>>> "Todd" == Todd <[EMAIL PROTECTED]> writes: >> > Jes Sorensen wrote: > > It took me a little while in the >> beginning to convince Alteon to open > > up and provide docs, but >> since they saw the light they have been > > extremely helpful and >> went much further in their openness than I had > > ever expected or >> dared to hope for. > > And now it's really showing in their >> favour. An amazing number of > research groups are writing >> applications to run on the Alteon cards. Todd> While I agree with what's going on right now, the recent Todd> purchase of Alteon by Nortel (primarily for their switch line, Todd> not for the NICs) leaves quite a bit of doubt in my mind about Todd> the future of the card and the openness of the firmware in Todd> particular. This is kinda running off topic, but lets give them the benefit of the doubt. The guys at Alteon knew what they did when they opened up. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Whining about MIME formatted email
> "Horst" == Horst von Brand <[EMAIL PROTECTED]> writes: Horst> "Albert D. Cahalan" <[EMAIL PROTECTED]> said: [...] >> That would be the "H=F8jland" in your .sig, right? No problem, '=' >> is a standard character. >> >> My MUA has been RFC-compliant since before this "MIME" thing >> existed, so I can see the full ASCII character set. That includes >> the carat, underscore, back tick, backslash, vertical bar, at >> symbol, octothorpe, and both braces. Horst> That is a really upsetting US/ASCII/English-centric view. How Horst> would you feel if the prevalent, "standard" character set Horst> didn't include 'h' and _your_ name showed up as "Albert Horst> D. Ca=68alan" elsewhere?! So? I have one of those letters in my name as well, doesn't mean I put it in the From line or in the code that I write. Or do you want us all to start using a compiler and editors that will understand full UTF8 so everybody who use non roman character sets have their names displayed correctly in the comments of the code? The kernel is written in C, C is in ASCII so whats the problem? Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Whining about MIME formatted email
> "Kurt" == Kurt Garloff <[EMAIL PROTECTED]> writes: Kurt> On Fri, Sep 08, 2000 at 06:33:34PM +1100, Keith Owens wrote: >> Exmh handles MIME just fine and MIME is useful for some things. >> Other people (including Linus) have made it clear that MIME is not >> welcome on linux-kernel, plain text format is always better when >> you are sending plain text. What next, rich text format and HTML >> with multiple copies of the text, MSWord format? Kurt> Stop making stupid statements like this, please, and comparing Kurt> well-defined RFC standards with proprietary formats. MIME is a Kurt> way for people that happen to use non 7bit characters to be able Kurt> to print their name correctly, even in presence of MTAs Kurt> somewhere in between that don't handle 8bit. Or with PGP, which Kurt> also prefers 7bit ... You'll probably complain about me using a Kurt> GnuPG signature as well. You do not need 8 bit characters in kernel code it's as simple as that. If you really insist, then post the patch in pure 8 bit, quoted-unreadable is brain damage and deserves to die the sooner the better. If there is a broken mail server somewhere in the way (which is really really rare these days) let the people who are behind that server suffer and not everybody else. Besides, quoted-unreadable makes it hard to just do patch < $MAILDIR/linux-kernel/ Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiler warnings
> "Keith" == Keith Owens <[EMAIL PROTECTED]> writes: Keith> On Wed, 6 Sep 2000 21:49:44 +0100 (BST), Alan Cox Keith> <[EMAIL PROTECTED]> wrote: >> Use a different gcc. There are reasons people shipping 2.96 for >> intel x86 also include egcs. The kernel isnt ready for 2.96 Keith> Out of curiousity, which compiler would you recommend for IA64 Keith> kernels? The latest unwind code is in the bleeding edge Keith> version of gcc, which just happens to have the problems with Keith> '##' as well. 2.96 but not the latest snapshot from Jim right now, follow the [EMAIL PROTECTED] list for recommendations. The discussion in question here was about 2.2.x anyway and there is no support for ia64 in that kernel. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jamie" == Jamie Lokier <[EMAIL PROTECTED]> writes: Jamie> According to group legend here (I wasn't around but will repeat Jamie> what I was told), we spent about 1 year trying to get docs on Jamie> Intel's i960 based gigabit card so we could program it. Jamie> Eventually we gave up and moved to Alteon, who are very Jamie> helpful. Heh It took me a little while in the beginning to convince Alteon to open up and provide docs, but since they saw the light they have been extremely helpful and went much further in their openness than I had ever expected or dared to hope for. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jamie" == Jamie Lokier [EMAIL PROTECTED] writes: Jamie According to group legend here (I wasn't around but will repeat Jamie what I was told), we spent about 1 year trying to get docs on Jamie Intel's i960 based gigabit card so we could program it. Jamie Eventually we gave up and moved to Alteon, who are very Jamie helpful. Heh It took me a little while in the beginning to convince Alteon to open up and provide docs, but since they saw the light they have been extremely helpful and went much further in their openness than I had ever expected or dared to hope for. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiler warnings
"Keith" == Keith Owens [EMAIL PROTECTED] writes: Keith On Wed, 6 Sep 2000 21:49:44 +0100 (BST), Alan Cox Keith [EMAIL PROTECTED] wrote: Use a different gcc. There are reasons people shipping 2.96 for intel x86 also include egcs. The kernel isnt ready for 2.96 Keith Out of curiousity, which compiler would you recommend for IA64 Keith kernels? The latest unwind code is in the bleeding edge Keith version of gcc, which just happens to have the problems with Keith '##' as well. 2.96 but not the latest snapshot from Jim right now, follow the [EMAIL PROTECTED] list for recommendations. The discussion in question here was about 2.2.x anyway and there is no support for ia64 in that kernel. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Whining about MIME formatted email
"Horst" == Horst von Brand [EMAIL PROTECTED] writes: Horst "Albert D. Cahalan" [EMAIL PROTECTED] said: [...] That would be the "H=F8jland" in your .sig, right? No problem, '=' is a standard character. My MUA has been RFC-compliant since before this "MIME" thing existed, so I can see the full ASCII character set. That includes the carat, underscore, back tick, backslash, vertical bar, at symbol, octothorpe, and both braces. Horst That is a really upsetting US/ASCII/English-centric view. How Horst would you feel if the prevalent, "standard" character set Horst didn't include 'h' and _your_ name showed up as "Albert Horst D. Ca=68alan" elsewhere?! So? I have one of those letters in my name as well, doesn't mean I put it in the From line or in the code that I write. Or do you want us all to start using a compiler and editors that will understand full UTF8 so everybody who use non roman character sets have their names displayed correctly in the comments of the code? The kernel is written in C, C is in ASCII so whats the problem? Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Todd" == Todd [EMAIL PROTECTED] writes: Jes Sorensen wrote: It took me a little while in the beginning to convince Alteon to open up and provide docs, but since they saw the light they have been extremely helpful and went much further in their openness than I had ever expected or dared to hope for.And now it's really showing in their favour. An amazing number of research groups are writing applications to run on the Alteon cards. Todd While I agree with what's going on right now, the recent Todd purchase of Alteon by Nortel (primarily for their switch line, Todd not for the NICs) leaves quite a bit of doubt in my mind about Todd the future of the card and the openness of the firmware in Todd particular. This is kinda running off topic, but lets give them the benefit of the doubt. The guys at Alteon knew what they did when they opened up. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Whining about MIME formatted email
"David" == David Ford [EMAIL PROTECTED] writes: David C program instructions are in ASCII, data certainly isn't David restricted to that. If you or your M*A can't or won't deal David with anything but plain text, then filter it. Plain text is David clearly in the minority of emails throughout the world and the David people on LKML seem in general not to care about MIME and David frequently use it. Let's end this offtopic thread please. Says the guy who puts his response in front of the quoted text which violates rfc1855 and adds a vcard you really expect people to take you serious? Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
acenic-v0.46 update
Hi
Here is a patch for the acenic-v0.46 driver relative to whats in
test8-pre4 - it solves a few bugs and cleans up a few minor issues in
the code and comments.
I have been unable to test this patch but looking over the changes I
cannot see any reason why it would cause problems.
Jes
--- ../linux/drivers/net/acenic.c Fri Jul 28 15:47:19 2000
+++ drivers/net/acenic.cTue Sep 5 15:21:11 2000
@@ -29,7 +29,12 @@
* infrastructure and Sparc support
* Pierrick Pinasseau (CERN): For lending me an Ultra 5 to test the
* driver under Linux/Sparc64
- * Matt Domsch <[EMAIL PROTECTED]>: Detect 1000baseT cards
+ * Matt Domsch <[EMAIL PROTECTED]>: Detect Alteon 1000baseT cards
+ * Chip Salzenberg <[EMAIL PROTECTED]>: Fix race condition between tx
+ * handler and close() cleanup.
+ * Ken Aaker <[EMAIL PROTECTED]>: Correct check for whether
+ * memory mapped IO is enabled to
+ * make the driver work on RS/6000.
*/
#include
@@ -83,8 +88,13 @@
#define PCI_VENDOR_ID_NETGEAR 0x1385
#define PCI_DEVICE_ID_NETGEAR_GA6200x620a
#endif
+#ifndef PCI_DEVICE_ID_NETGEAR_GA620T
+#define PCI_DEVICE_ID_NETGEAR_GA620T 0x630a
+#endif
+
/*
- * They used the DEC vendor ID by mistake
+ * Farallon used the DEC vendor ID by mistake and they seem not
+ * to care - stinky!
*/
#ifndef PCI_DEVICE_ID_FARALLON_PN9000SX
#define PCI_DEVICE_ID_FARALLON_PN9000SX0x1a
@@ -389,7 +399,7 @@
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
static const char __initdata *version =
- "acenic.c: v0.44 05/11/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
+ "acenic.c: v0.46 09/05/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
static struct net_device *root_dev = NULL;
@@ -429,7 +439,8 @@
!((pdev->vendor == PCI_VENDOR_ID_3COM) &&
(pdev->device == PCI_DEVICE_ID_3COM_3C985)) &&
!((pdev->vendor == PCI_VENDOR_ID_NETGEAR) &&
- (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620)) &&
+ ((pdev->device == PCI_DEVICE_ID_NETGEAR_GA620) ||
+ (pdev->device == PCI_DEVICE_ID_NETGEAR_GA620T))) &&
/*
* Farallon used the DEC vendor ID on their cards by
* mistake for a while
@@ -480,7 +491,7 @@
pci_read_config_word(pdev, PCI_COMMAND, >pci_command);
/* OpenFirmware on Mac's does not set this - DOH.. */
- if (!ap->pci_command & PCI_COMMAND_MEMORY) {
+ if (!(ap->pci_command & PCI_COMMAND_MEMORY)) {
printk(KERN_INFO "%s: Enabling PCI Memory Mapped "
"access - was not enabled by BIOS/Firmware\n",
dev->name);
@@ -597,7 +608,6 @@
}
-#ifdef MODULE
MODULE_AUTHOR("Jes Sorensen <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("AceNIC/3C985/GA620 Gigabit Ethernet driver");
MODULE_PARM(link, "1-" __MODULE_STRING(8) "i");
@@ -607,7 +617,6 @@
MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i");
-#endif
void __exit ace_module_cleanup(void)
{
@@ -1994,18 +2003,34 @@
if (txcsm != idx) {
do {
struct sk_buff *skb;
- dma_addr_t mapping;
skb = ap->skb->tx_skbuff[idx].skb;
- mapping = ap->skb->tx_skbuff[idx].mapping;
+ /*
+* Race condition between the code cleaning
+* the tx queue in the interrupt handler and the
+* interface close,
+*
+* This is a kludge that really should be fixed
+* by preventing the driver from generating a tx
+* interrupt when the packet has already been
+* removed from the tx queue.
+*
+* Nailed by Don Dugger and Chip Salzenberg of
+* VA Linux.
+*/
+ if (skb) {
+ dma_addr_t mapping;
- ap->stats.tx_packets++;
- ap->stats.tx_bytes += skb->len;
- pci_unmap_single(ap->pdev, mapping, skb->len,
-
acenic-v0.46 update
Hi
Here is a patch for the acenic-v0.46 driver relative to whats in
test8-pre4 - it solves a few bugs and cleans up a few minor issues in
the code and comments.
I have been unable to test this patch but looking over the changes I
cannot see any reason why it would cause problems.
Jes
--- ../linux/drivers/net/acenic.c Fri Jul 28 15:47:19 2000
+++ drivers/net/acenic.cTue Sep 5 15:21:11 2000
@@ -29,7 +29,12 @@
* infrastructure and Sparc support
* Pierrick Pinasseau (CERN): For lending me an Ultra 5 to test the
* driver under Linux/Sparc64
- * Matt Domsch [EMAIL PROTECTED]: Detect 1000baseT cards
+ * Matt Domsch [EMAIL PROTECTED]: Detect Alteon 1000baseT cards
+ * Chip Salzenberg [EMAIL PROTECTED]: Fix race condition between tx
+ * handler and close() cleanup.
+ * Ken Aaker [EMAIL PROTECTED]: Correct check for whether
+ * memory mapped IO is enabled to
+ * make the driver work on RS/6000.
*/
#include linux/config.h
@@ -83,8 +88,13 @@
#define PCI_VENDOR_ID_NETGEAR 0x1385
#define PCI_DEVICE_ID_NETGEAR_GA6200x620a
#endif
+#ifndef PCI_DEVICE_ID_NETGEAR_GA620T
+#define PCI_DEVICE_ID_NETGEAR_GA620T 0x630a
+#endif
+
/*
- * They used the DEC vendor ID by mistake
+ * Farallon used the DEC vendor ID by mistake and they seem not
+ * to care - stinky!
*/
#ifndef PCI_DEVICE_ID_FARALLON_PN9000SX
#define PCI_DEVICE_ID_FARALLON_PN9000SX0x1a
@@ -389,7 +399,7 @@
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
static const char __initdata *version =
- "acenic.c: v0.44 05/11/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
+ "acenic.c: v0.46 09/05/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
static struct net_device *root_dev = NULL;
@@ -429,7 +439,8 @@
!((pdev-vendor == PCI_VENDOR_ID_3COM)
(pdev-device == PCI_DEVICE_ID_3COM_3C985))
!((pdev-vendor == PCI_VENDOR_ID_NETGEAR)
- (pdev-device == PCI_DEVICE_ID_NETGEAR_GA620))
+ ((pdev-device == PCI_DEVICE_ID_NETGEAR_GA620) ||
+ (pdev-device == PCI_DEVICE_ID_NETGEAR_GA620T)))
/*
* Farallon used the DEC vendor ID on their cards by
* mistake for a while
@@ -480,7 +491,7 @@
pci_read_config_word(pdev, PCI_COMMAND, ap-pci_command);
/* OpenFirmware on Mac's does not set this - DOH.. */
- if (!ap-pci_command PCI_COMMAND_MEMORY) {
+ if (!(ap-pci_command PCI_COMMAND_MEMORY)) {
printk(KERN_INFO "%s: Enabling PCI Memory Mapped "
"access - was not enabled by BIOS/Firmware\n",
dev-name);
@@ -597,7 +608,6 @@
}
-#ifdef MODULE
MODULE_AUTHOR("Jes Sorensen [EMAIL PROTECTED]");
MODULE_DESCRIPTION("AceNIC/3C985/GA620 Gigabit Ethernet driver");
MODULE_PARM(link, "1-" __MODULE_STRING(8) "i");
@@ -607,7 +617,6 @@
MODULE_PARM(rx_coal_tick, "1-" __MODULE_STRING(8) "i");
MODULE_PARM(max_rx_desc, "1-" __MODULE_STRING(8) "i");
-#endif
void __exit ace_module_cleanup(void)
{
@@ -1994,18 +2003,34 @@
if (txcsm != idx) {
do {
struct sk_buff *skb;
- dma_addr_t mapping;
skb = ap-skb-tx_skbuff[idx].skb;
- mapping = ap-skb-tx_skbuff[idx].mapping;
+ /*
+* Race condition between the code cleaning
+* the tx queue in the interrupt handler and the
+* interface close,
+*
+* This is a kludge that really should be fixed
+* by preventing the driver from generating a tx
+* interrupt when the packet has already been
+* removed from the tx queue.
+*
+* Nailed by Don Dugger and Chip Salzenberg of
+* VA Linux.
+*/
+ if (skb) {
+ dma_addr_t mapping;
- ap-stats.tx_packets++;
- ap-stats.tx_bytes += skb-len;
- pci_unmap_single(ap-pdev, mapping, skb-len,
-PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(skb);
+ mapping = ap-skb-tx_skbuff[idx].mapping;
+
+ ap-stats.tx_packets+
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> IPX is a really good LAN protocol (but totally sucks for Jeff> internet). A full blown NCP server in-kernel that's toughtly Jeff> coupled to the page cache running over IPX would make flames Jeff> shoot out of the back of a Linux server, and make NT like look Jeff> an old lady hobbling down the street. There's no need to Jeff> configure client addresses with it, and for file and print, it's Jeff> the best. IPX is WHAT? I'd recommend you go look at the switches on your network and note how they look likg flashing chrstmas trees - broadcast traffic is not good for any type of network, be it LAN or WAN. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x driver audit help
> "Frank" == Frank Davis <[EMAIL PROTECTED]> writes: Frank> Hello all, Anyone wishing to re-audit the drivers/block and Frank> drivers/char for locking issues and submit their patches to me Frank> directly, feel free. I think if more people comb through the Frank> code than myself, patches I missed will be found (100 eyes are Frank> better than 2). Once I think I have all the neccessary patches, Frank> blessed by the current maintainers, then I'll submit the Frank> patches to Linus for a finally blessing for inclusion into Frank> 2.4.0. Regards, Frank [EMAIL PROTECTED] It would be a lot more useful if you posted incremental patches here instead of doing a giant mega patch once you decide it's done. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> Intel Nitro Card - i960 processor on the card. The SMP Jeff> debugging involved the use of a bus analyser since this card had Jeff> a piggish memory bus footprint (i960 processors do not have an Jeff> IO address space, so everything is memory mapped. The big Jeff> weakness of early I2O stuff was that the I960 running off on the Jeff> boards had access to the memory bus of these early systems. Jeff> Performace problems that were related to passing messages to the Jeff> embedded OS running on the i960 on the Nitro Card, and it Jeff> "missing" messages when two processors were talking to it at Jeff> once. True the i960 based one I didn't think of, however Intel never provided docs for it. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> Ingo Molnar wrote: >> you dont contribute a bit to the generic kernel and the kernel >> infrastructure itself. Jeff> I contribute code, time, and $$$, Ingo. HAve you contributed code to anything but your own private project which you have just declared to be withdrawn so you can go stick it into your own custom OS? I don't remember seeing you contribute code to any other part of the kernel, besides scream about bugs in the kernel that shows up to be bugs in your compiler etc. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
>>>>> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> Jes Sorensen wrote: >> True the i960 based one I didn't think of, however Intel never >> provided docs for it. Jeff> ??? I find this surprising. Email [EMAIL PROTECTED] and ask Jeff> him if they will give them to you. I'm sure they would for Jeff> Linux. Well you obviously never had to deal with some of these companies. I have little interest in writing a driver for a card which I don't have and which is very old. I know that Don Becker had problems in the past getting proper specs out on some of the other Intel cards, I don't know whether he tried to get specs on the Nitro but I would asume so. >From Don's web page about unsupported boards: "No board with an on-board processor is supported, because these invariably have a proprietary/undocumented interface. (EEPro Server and Matrox multiport PCI switch cards fall into this category.)". Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> Only Linux makes the lights flash with IPX RIP/SAP. NetWare Jeff> uses NLSP routing and has since 1993 for IPX/SPX. I agree if Jeff> someone is running NetWare 3 or NetWare 4.1 or earlier there's a Jeff> lot of RIP/SAP traffic, but not the NLSP versions -- they do not Jeff> use RIP/SAP but NLSP. Well I looked at the switches for NT installations not Linux boxes, it was a sad sight. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff Only Linux makes the lights flash with IPX RIP/SAP. NetWare Jeff uses NLSP routing and has since 1993 for IPX/SPX. I agree if Jeff someone is running NetWare 3 or NetWare 4.1 or earlier there's a Jeff lot of RIP/SAP traffic, but not the NLSP versions -- they do not Jeff use RIP/SAP but NLSP. Well I looked at the switches for NT installations not Linux boxes, it was a sad sight. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x driver audit help
"Frank" == Frank Davis [EMAIL PROTECTED] writes: Frank Hello all, Anyone wishing to re-audit the drivers/block and Frank drivers/char for locking issues and submit their patches to me Frank directly, feel free. I think if more people comb through the Frank code than myself, patches I missed will be found (100 eyes are Frank better than 2). Once I think I have all the neccessary patches, Frank blessed by the current maintainers, then I'll submit the Frank patches to Linus for a finally blessing for inclusion into Frank 2.4.0. Regards, Frank [EMAIL PROTECTED] It would be a lot more useful if you posted incremental patches here instead of doing a giant mega patch once you decide it's done. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff IPX is a really good LAN protocol (but totally sucks for Jeff internet). A full blown NCP server in-kernel that's toughtly Jeff coupled to the page cache running over IPX would make flames Jeff shoot out of the back of a Linux server, and make NT like look Jeff an old lady hobbling down the street. There's no need to Jeff configure client addresses with it, and for file and print, it's Jeff the best. IPX is WHAT? I'd recommend you go look at the switches on your network and note how they look likg flashing chrstmas trees - broadcast traffic is not good for any type of network, be it LAN or WAN. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What the Heck? [Fwd: Returned mail: User unknown]
> "Ricky" == Ricky Beam <[EMAIL PROTECTED]> writes: Ricky> On Sun, 3 Sep 2000, Horst von Brand wrote: >> Much more of a reason to get them to clean up their act! Ricky> Excuse me? How the hell do you expect them to "clean up their Ricky> act" when their "dialup" users are the problem? Are you gonna Ricky> scan 250,000 machines to make sure they aren't running SMTP Ricky> servers? Trap all port 25 traffic? Ricky> It's the same problem EVERY ISP has. RR is just higher profile Ricky> because of the number of users. Cable/DSL are unlike Ricky> traditional dialup in that you are always connected as long as Ricky> the machine is on. And as usual the solution is dead easy, in the subscriber policy the users have to sign you add a statement prohibiting open relays. If the ISP gets a complaint about a user still doing this, they verify it and close the account. Problem solved. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes: Richard> I thought you said some of the GigE drivers supported this? Richard> Or were you just saying that the GigE cards were some of the Richard> few which supported scatter/gather DMA and IP checksumming? The latter. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: Ingo> On Mon, 4 Sep 2000 [EMAIL PROTECTED] wrote: >> The experiment showed the following prefetching could reduce 20-30% >> of csum_partial_copy_generic() execution time. Ingo> Please test it and post the numbers. csum_partial_copy_generic() Ingo> already does prefetching - the real test would be to check Ingo> lat_tcp and bw_tcp numbers over gigabit, with and without this Ingo> patch applied. (the same numbers over localhost dont really Ingo> count.) Eg. we had smart KNI-based memcpy routines as well, and Ingo> it turned out that bw_tcp over gigabit actually got Ingo> slower. [testing over 100mbit isnt enough obviously because x86 Ingo> CPUs csum much faster than that.] Thats a surprise to me, I remember better performance when I played with Doug's KNI patches back in the beginning. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jamie" == Jamie Lokier <[EMAIL PROTECTED]> writes: Jamie> Nice point! Only valid for TCP & UDP though. Jamie> When people want _real_ low latency, they don't use TCP or UDP, Jamie> and they certainly don't put data checksums at the start. They Jamie> still aim for zero copies. That pass, even over cached data, Jamie> is still significant. In this case you really want to do a user space driver implementation to avoid the cost of context switches. This is how a lot of people use the Myrinet (afaik) and there were also some of the guys at CERN who did a similar driver for the AceNIC at the same time I wrote the first version of the 'normal' driver. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: Ingo> On Sun, 3 Sep 2000, Andi Kleen wrote: >> I did the same for fragment RX some months ago (simple fragment >> lists that were copy-checksummed to user space). Overall it is >> probably better to use a kiovec, because that can be more easily >> used in nfsd and sendfile. Ingo> the basic fragment type introduced by the TUX changes is a Ingo> 'struct skb_frag', which has csum, size, *page, page_offset, Ingo> frag_done, *data and *private fields - this is more than normal Ingo> kiovecs offer. But i think kiovecs can be extended to do all Ingo> this (if Stephen & everybody else agrees), i just didnt want to Ingo> touch it for the time being. I'd love to see this transferred to kiobufs, I'd prefer not to see yet another structure introduced ;-) At OLS we discussed a design for this, I think the consencus was to keep the data field in the old skb and allow this to be used by the old driver (receive path) and for building headers for tx packets. Then one can either optionally do a linearized skb with everything in the data field for the old hardware or stick pointers to data in a kiobuf. I set up a mailing list for these discussions at [EMAIL PROTECTED] ([EMAIL PROTECTED]) to subscribe. It's been fairly quiet so far, but I'd like to see more action. Ok, I'll go read your code next. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes: Richard> Andrew Morton writes: >> All of them except the 3c905 provide hardware Rx and Tx >> checksumming of IP, TCP and UDP headers. No 64 bit addressing >> support. Richard> And does the driver support it? Has anyone benchmarked the Richard> performance difference (if any)? There isn't much gain from using it when we can't do zero copy xmits in the first place. It might be worth enabling for receive though. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Richard" == Richard Gooch [EMAIL PROTECTED] writes: Richard Andrew Morton writes: All of them except the 3c905 provide hardware Rx and Tx checksumming of IP, TCP and UDP headers. No 64 bit addressing support. Richard And does the driver support it? Has anyone benchmarked the Richard performance difference (if any)? There isn't much gain from using it when we can't do zero copy xmits in the first place. It might be worth enabling for receive though. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Ingo" == Ingo Molnar [EMAIL PROTECTED] writes: Ingo On Sun, 3 Sep 2000, Andi Kleen wrote: I did the same for fragment RX some months ago (simple fragment lists that were copy-checksummed to user space). Overall it is probably better to use a kiovec, because that can be more easily used in nfsd and sendfile. Ingo the basic fragment type introduced by the TUX changes is a Ingo 'struct skb_frag', which has csum, size, *page, page_offset, Ingo frag_done, *data and *private fields - this is more than normal Ingo kiovecs offer. But i think kiovecs can be extended to do all Ingo this (if Stephen everybody else agrees), i just didnt want to Ingo touch it for the time being. I'd love to see this transferred to kiobufs, I'd prefer not to see yet another structure introduced ;-) At OLS we discussed a design for this, I think the consencus was to keep the data field in the old skb and allow this to be used by the old driver (receive path) and for building headers for tx packets. Then one can either optionally do a linearized skb with everything in the data field for the old hardware or stick pointers to data in a kiobuf. I set up a mailing list for these discussions at [EMAIL PROTECTED] ([EMAIL PROTECTED]) to subscribe. It's been fairly quiet so far, but I'd like to see more action. Ok, I'll go read your code next. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jamie" == Jamie Lokier [EMAIL PROTECTED] writes: Jamie Nice point! Only valid for TCP UDP though. Jamie When people want _real_ low latency, they don't use TCP or UDP, Jamie and they certainly don't put data checksums at the start. They Jamie still aim for zero copies. That pass, even over cached data, Jamie is still significant. In this case you really want to do a user space driver implementation to avoid the cost of context switches. This is how a lot of people use the Myrinet (afaik) and there were also some of the guys at CERN who did a similar driver for the AceNIC at the same time I wrote the first version of the 'normal' driver. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Richard" == Richard Gooch [EMAIL PROTECTED] writes: Richard I thought you said some of the GigE drivers supported this? Richard Or were you just saying that the GigE cards were some of the Richard few which supported scatter/gather DMA and IP checksumming? The latter. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What the Heck? [Fwd: Returned mail: User unknown]
"Ricky" == Ricky Beam [EMAIL PROTECTED] writes: Ricky On Sun, 3 Sep 2000, Horst von Brand wrote: Much more of a reason to get them to clean up their act! Ricky Excuse me? How the hell do you expect them to "clean up their Ricky act" when their "dialup" users are the problem? Are you gonna Ricky scan 250,000 machines to make sure they aren't running SMTP Ricky servers? Trap all port 25 traffic? Ricky It's the same problem EVERY ISP has. RR is just higher profile Ricky because of the number of users. Cable/DSL are unlike Ricky traditional dialup in that you are always connected as long as Ricky the machine is on. And as usual the solution is dead easy, in the subscriber policy the users have to sign you add a statement prohibiting open relays. If the ISP gets a complaint about a user still doing this, they verify it and close the account. Problem solved. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Ingo" == Ingo Molnar [EMAIL PROTECTED] writes: Ingo On Mon, 4 Sep 2000 [EMAIL PROTECTED] wrote: The experiment showed the following prefetching could reduce 20-30% of csum_partial_copy_generic() execution time. Ingo Please test it and post the numbers. csum_partial_copy_generic() Ingo already does prefetching - the real test would be to check Ingo lat_tcp and bw_tcp numbers over gigabit, with and without this Ingo patch applied. (the same numbers over localhost dont really Ingo count.) Eg. we had smart KNI-based memcpy routines as well, and Ingo it turned out that bw_tcp over gigabit actually got Ingo slower. [testing over 100mbit isnt enough obviously because x86 Ingo CPUs csum much faster than that.] Thats a surprise to me, I remember better performance when I played with Doug's KNI patches back in the beginning. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
>>>>> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes: Andrew> Jes Sorensen wrote: >> I only know of a few 100baseT cards that can do it such as the >> Adaptec Starfire and the 3C905B (though I am not sure what it >> provides is sufficient). Andrew> The 3c905, 3c905B, 3c905C and all 3Com Cardbus NICs will do Andrew> scatter and gather of up to 63 fragments per packet with Andrew> byte-granular fragment alignment and length. Andrew> All of them except the 3c905 provide hardware Rx and Tx Andrew> checksumming of IP, TCP and UDP headers. No 64 bit addressing Andrew> support. Read what I wrote above, the 905B was on the list I posted ;-) The 905B is not a 1995 card on the other hand. The 905 doesn't count since scatter/gather without checksumming makes it pretty useless. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> There's been a few cards around since about 1995, but I don't Jeff> remember all of them. I do remember having to debug SMP code on Jeff> them though -- yec I wouldn't be surprised but I would prefer names. Doing SMP aware device drivers is not hard though. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: zero-copy TCP]
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> He said memory to memory transfers. I also said data aquisition servers to data processing clients. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> **ALL** Netware network drivers support a scatter/gather Jeff> proramming interface, whether the hardware does or not. In Jeff> NetWare, the drivers get passed a fragment list in what's called Jeff> an ECB (Event Control Block). It's the drivers responsiblity to Jeff> assemble the fragment lists. We did it this way to support Jeff> scatter/gather cards and non-scatter gather cards in one Jeff> interface. Those drivers that do not support scatter gather DMA Jeff> operations copy to a local buffer to assemble the packet. Those Jeff> with a shared memory window copy data from the fragment list Jeff> into this window until a complete IEEE frame gets completed Jeff> (since it will get copied anyway), then hit the register bits to Jeff> initiate a send of the data. You just told us earlier in the thread that NetWare does direct zero copy DMA but thats only half the story obviously. Up until the era of Gigabit Ethernet cards there were almost no PCI cards available that would do scatter/gather so obviously netware wasn't doing zero copy either. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: zero-copy TCP]
>>>>> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> Jes Sorensen wrote: >> I'd love to see a netware box sustain 110MB/sec (MB as in mega >> byte) memory to memory in two TCP streams between dual 400MHz P2 >> boxes. Jeff> What the hell does a NUMA interconnect have to do with Jeff> networking. Who would be braindead enough to waste processing Jeff> cycles passing Network data over a NUMA fabric anyway. There's Jeff> a lot more efficient ways to connect to boxes with NUMA than Jeff> using a TCPIP stack on a NUMA interconnect. NUMA? whats NUMA got to do with this? I am talking Gigabit Ethernet with Jumbo frames on standard commodity hardware between two standard 440BX based PCs. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: [since you like to forward things after sending me a private email, I'll do the same]. Jeff> I wrote the SMP ODI networking layer in NetWare that used today by Jeff> over 90,000,000 NetWare users. I also wrote the SMP LLC8022 Jeff> Stack, the SMP IPX/SPX Stack, and the SMP OSPF TCPIP stack in Jeff> NetWare. I think I know what the hell I'm doing here. Most Jeff> Network protocols assume a primary/secondary relationship. The Jeff> faster you can get requests in and out of a server, the faster the Jeff> response time on the client for remote file system operation. You look at network file system issues and generalize that to generic networking. I am sorry but I do not think you know a whole lot about high speed networking. You forget that when talking about fast networking it depends on what you define as fast. Some people consider file serving performance others are interested in fast memory to memory transfers (from data aquisition servers to client processing units for instance). For bulk data transfers on high speed networks (note I do not consider 100Mbit/sec Fast Ethernet as being a fast network) the real here issue is pipelining through socket buffers and large TCP windows and not latency. Besides, the fact that there are 90M netware boxes around doesn't matter when most of them are running IPX - IPX is braindamage and has nothing to do with proper networking. Jeff> What I wrote is THREE TIMES FASTER THAN WHAT'S IN LINUX. Care to Jeff> do a challenge. Let's take my NetWare code and see which is Jeff> faster and lower latency on a Network. Mine or Linux's. I bet Jeff> you $100.00 it will beat the Linux code in every test. I'd love to see a netware box sustain 110MB/sec (MB as in mega byte) memory to memory in two TCP streams between dual 400MHz P2 boxes. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> all over the place that increases latency. Not to mention the Jeff> overhead of the type of interrupt and trap gates that suck up Jeff> about 50 clocks to fetch the IDT, PDE, and GDT tables for every Jeff> interrupt. NetWare copies nothing in TCPIP except at the stream Jeff> head. Why do you need to copy data anyway to checksum an IP Jeff> packet anyway? I noticed you do the right thing and keep the Jeff> headers and data as separate fragments during header Jeff> construction, so why do you need to copy data for checksumming? Because your hardware doesn't do scatter/gather DMA *and* TCP TX checksumming - only very few cards do. You have to build every packet in memory if the card doesn't do sct/gat since you can't really send out data without IP headers in front of it. And if your card doesn't do TX transmit then you have to run over all the data with the CPU to calculate the checksum and once you do this you can just as well do the full copy. Also note that many cards that do sct/gth also have a bit of latency per descriptor so you do not want to use 10 descriptors for a 1500 byte packet. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> KDB is putrid. Can it debug double faults? NO. Can it debug Jeff> complex register and numeric evaluation statements like IF ((EAX Jeff> == 1) && [ESP-4] == 0x3000)? NO. Can it debug nested task gate Jeff> exceptions? NO. Can it debug SMP locks races? NO. Can it Jeff> debug priority inversion problems in sleep locks? NO. Oh you're telling us that you are not able to figure out what those lines of C turn into in assembly so you can set a break point yourself? Jeff> Can the Kernel debugger in NetWare? YES. Can the Kernel Jeff> Debugger in NT? YES. Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff, could you start by learning to quote email and not send a full copy of the entire email you reply to (read rfc1855). Jeff> The entire Linux Network subsystem needs an overhaul. The code Jeff> copies data all over the place. I am at present pulling it apart Jeff> and porting it to MANOS, and what a mess indeed. In NetWare, the Jeff> only time data ever gets copied from incoming packets is: Try and understand the code before you make such bold statements. Jeff> 1. A copy to userspace at a stream head. 2. An incoming write Jeff> that gets copied into the file cache. Jeff> Reads from cache are never copied. In fact, the network server Jeff> locks a file cache page and sends it unaltered to the network Jeff> drivers and DMA's directly from it. Since NetWare has WTD's Jeff> these I/O requests get processed at the highest possible Jeff> priority. In networking, the enemy is LATENCY for fast Jeff> performance. That's why NetWare can handle 5000 users and Linux Jeff> barfs on 100 in similiar tests. Copying increases latency, and Jeff> the long code paths in the Linux Network layer. You can't DMA directly from a file cache page unless you have a network card that does scatter/gather DMA and surprise surprise, 80-90% of the cards on the market don't support this. Besides that you need to do copy-on-write if you want to be able to do zero copy on write() from user space, marking data copy on write is *expensive* on x86 SMP boxes since you have to modify the tlb on all processors. On top of that you have to look at the packet size, for small packets a copy is often a lot cheaper than modifying the page tables, even on UP systems so you need a copy/break scheme here. As wrt your statement on latency then it's nice to see that you don't know what you are talking about. Latency is one issue in fast networking it's far from the only one. Latency is important for message passing type applications however for bulk data transfers it's less relevant since you really want deep pipelining here and properly written applications. If you TCP window is too small even zero latency will only buy you soo much on a really fast network. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes: Jeff> TRG has reprioritized it's long term objectives, and due to Jeff> resource constraints and short term schedules, the Open Source Jeff> NDS and Open Source NTFS File System projects are being Jeff> withdrawn from the Linux Initiative. These projects will be Jeff> MANOS only, and any interested party is free to acquire the code Jeff> and back port them into Linux, though the networking Jeff> architectures are profoundly different between the two. The Jeff> lack of a Kernel Debugger and other basic kernel level Jeff> facilities on Linux make TRG's job about 20 times harder on Jeff> Linux and take almost 10 times as long as is possible on NT, Jeff> NetWare, or MANOS to develop software asa result ofthis. If you want to pull out just do so. However, if you need an excuse please try to use facts and not vapour: we do have a kernel debugger for instance. It's called KDB and has been around for quite a while, you just have to download it and patch your kernel for it (which is not an unreasonable request if you are working on the kernel in the first place). Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: Ingo> On Sat, 2 Sep 2000, Dan Maas wrote: >> There are various other tricks that can be done to speed up network >> servers, like passing files directly from the buffer cache to the >> network card. This one is currently frowned upon by the Linux >> community, [...] Ingo> FYI, the TUX patch (released yesterday) includes a lightweight Ingo> zero-copy TCP implementation for the 2.4 Linux kernel. The Ingo> interface is not yet exported to user-space (simply because TUX Ingo> uses it from kernel-space so the user-space bits were not Ingo> needed), but the network driver framework and TCP-stack bits are Ingo> there, so the hard part is done. The two most widely used Ingo> gigabit drivers are 'converted' to support zero-copy, the Ingo> SysKonnect and the Acenic driver (the modifications are well Ingo> tested). I plan to add the user-space bits in the near future. Could you comment a bit on the design you used or do I have to go read the code? Some of us had a good chat at OLS about how to do zero copy TCP xmits by kiobufifying the skb's. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre2
> "David" == David S Miller <[EMAIL PROTECTED]> writes: >Date: Fri, 1 Sep 2000 19:01:18 +0100 (BST) From: Alan Cox > <[EMAIL PROTECTED]> >o Acenic 0.45 fixes (Chip Salzenberg) David> This adds a huge comment claiming to fix some race condition, David> but no actual code is changed. How can this be? :-) I guess Alan applied the patch earlier and now took the rest of the changes for the 'official' driver release. I have a few more patches coming up soon, look out for a v0.46 release coming to an http site near you within too long. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Ingo" == Ingo Molnar [EMAIL PROTECTED] writes: Ingo On Sat, 2 Sep 2000, Dan Maas wrote: There are various other tricks that can be done to speed up network servers, like passing files directly from the buffer cache to the network card. This one is currently frowned upon by the Linux community, [...] Ingo FYI, the TUX patch (released yesterday) includes a lightweight Ingo zero-copy TCP implementation for the 2.4 Linux kernel. The Ingo interface is not yet exported to user-space (simply because TUX Ingo uses it from kernel-space so the user-space bits were not Ingo needed), but the network driver framework and TCP-stack bits are Ingo there, so the hard part is done. The two most widely used Ingo gigabit drivers are 'converted' to support zero-copy, the Ingo SysKonnect and the Acenic driver (the modifications are well Ingo tested). I plan to add the user-space bits in the near future. Could you comment a bit on the design you used or do I have to go read the code? Some of us had a good chat at OLS about how to do zero copy TCP xmits by kiobufifying the skb's. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff TRG has reprioritized it's long term objectives, and due to Jeff resource constraints and short term schedules, the Open Source Jeff NDS and Open Source NTFS File System projects are being Jeff withdrawn from the Linux Initiative. These projects will be Jeff MANOS only, and any interested party is free to acquire the code Jeff and back port them into Linux, though the networking Jeff architectures are profoundly different between the two. The Jeff lack of a Kernel Debugger and other basic kernel level Jeff facilities on Linux make TRG's job about 20 times harder on Jeff Linux and take almost 10 times as long as is possible on NT, Jeff NetWare, or MANOS to develop software asa result ofthis. If you want to pull out just do so. However, if you need an excuse please try to use facts and not vapour: we do have a kernel debugger for instance. It's called KDB and has been around for quite a while, you just have to download it and patch your kernel for it (which is not an unreasonable request if you are working on the kernel in the first place). Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff KDB is putrid. Can it debug double faults? NO. Can it debug Jeff complex register and numeric evaluation statements like IF ((EAX Jeff == 1) [ESP-4] == 0x3000)? NO. Can it debug nested task gate Jeff exceptions? NO. Can it debug SMP locks races? NO. Can it Jeff debug priority inversion problems in sleep locks? NO. Oh you're telling us that you are not able to figure out what those lines of C turn into in assembly so you can set a break point yourself? Jeff Can the Kernel debugger in NetWare? YES. Can the Kernel Jeff Debugger in NT? YES. Yeah I bet NT also has a wonderful graphical click click wush wush environment for it that allows you to spend all your time `improving' your rsi instead of getting real work done. Have you ever looked at NT device driver code? I have, it's not pretty at all so I can understand why you need all these tools. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: [since you like to forward things after sending me a private email, I'll do the same]. Jeff I wrote the SMP ODI networking layer in NetWare that used today by Jeff over 90,000,000 NetWare users. I also wrote the SMP LLC8022 Jeff Stack, the SMP IPX/SPX Stack, and the SMP OSPF TCPIP stack in Jeff NetWare. I think I know what the hell I'm doing here. Most Jeff Network protocols assume a primary/secondary relationship. The Jeff faster you can get requests in and out of a server, the faster the Jeff response time on the client for remote file system operation. You look at network file system issues and generalize that to generic networking. I am sorry but I do not think you know a whole lot about high speed networking. You forget that when talking about fast networking it depends on what you define as fast. Some people consider file serving performance others are interested in fast memory to memory transfers (from data aquisition servers to client processing units for instance). For bulk data transfers on high speed networks (note I do not consider 100Mbit/sec Fast Ethernet as being a fast network) the real here issue is pipelining through socket buffers and large TCP windows and not latency. Besides, the fact that there are 90M netware boxes around doesn't matter when most of them are running IPX - IPX is braindamage and has nothing to do with proper networking. Jeff What I wrote is THREE TIMES FASTER THAN WHAT'S IN LINUX. Care to Jeff do a challenge. Let's take my NetWare code and see which is Jeff faster and lower latency on a Network. Mine or Linux's. I bet Jeff you $100.00 it will beat the Linux code in every test. I'd love to see a netware box sustain 110MB/sec (MB as in mega byte) memory to memory in two TCP streams between dual 400MHz P2 boxes. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: zero-copy TCP
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff **ALL** Netware network drivers support a scatter/gather Jeff proramming interface, whether the hardware does or not. In Jeff NetWare, the drivers get passed a fragment list in what's called Jeff an ECB (Event Control Block). It's the drivers responsiblity to Jeff assemble the fragment lists. We did it this way to support Jeff scatter/gather cards and non-scatter gather cards in one Jeff interface. Those drivers that do not support scatter gather DMA Jeff operations copy to a local buffer to assemble the packet. Those Jeff with a shared memory window copy data from the fragment list Jeff into this window until a complete IEEE frame gets completed Jeff (since it will get copied anyway), then hit the register bits to Jeff initiate a send of the data. You just told us earlier in the thread that NetWare does direct zero copy DMA but thats only half the story obviously. Up until the era of Gigabit Ethernet cards there were almost no PCI cards available that would do scatter/gather so obviously netware wasn't doing zero copy either. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: zero-copy TCP]
"Jeff" == Jeff V Merkey [EMAIL PROTECTED] writes: Jeff Jes Sorensen wrote: I'd love to see a netware box sustain 110MB/sec (MB as in mega byte) memory to memory in two TCP streams between dual 400MHz P2 boxes. Jeff What the hell does a NUMA interconnect have to do with Jeff networking. Who would be braindead enough to waste processing Jeff cycles passing Network data over a NUMA fabric anyway. There's Jeff a lot more efficient ways to connect to boxes with NUMA than Jeff using a TCPIP stack on a NUMA interconnect. NUMA? whats NUMA got to do with this? I am talking Gigabit Ethernet with Jumbo frames on standard commodity hardware between two standard 440BX based PCs. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre2
"David" == David S Miller [EMAIL PROTECTED] writes: Date: Fri, 1 Sep 2000 19:01:18 +0100 (BST) From: Alan Cox [EMAIL PROTECTED] o Acenic 0.45 fixes (Chip Salzenberg) David This adds a huge comment claiming to fix some race condition, David but no actual code is changed. How can this be? :-) I guess Alan applied the patch earlier and now took the rest of the changes for the 'official' driver release. I have a few more patches coming up soon, look out for a v0.46 release coming to an http site near you within too long. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
