Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[EXPERIMENTAL\s+PATCH\]\s+2\.4\s+tulip\s+jumbo\s+frames\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[EXPERIMENTAL\s+PATCH\]\s+2\.4\s+tulip\s+jumbo\s+frames\s*$/: 20 ]

Total 20 documents matching your query.

1. ers (score: 1): Author: xxxxxxxxxxx (Luis R. Rodriguez); Date: Thu, 27 May 2004 12:29:39 -0700; Whatever became of this? For what it's worth, I have been using a patch originally by Ben McKeegan that seems to work fine. But, I'd be happy for either of the patches to go in so long as we can fina; /archives/netdev/2004-05/msg00410.html (19,872 bytes)
2. [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Tue, 9 Dec 2003 16:06:35 +0100; Attached is a patch which enables jumbo frames on tulip based boards. It makes it possible to set an MTU of up to 2025 bytes. However, testing against an NE3200 board using 10base-2 shows assorted pr; /archives/netdev/2003-12/msg00158.html (8,460 bytes)
3. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 09 Dec 2003 09:28:23 -0800; Rask Ingemann Lambertsen wrote: Attached is a patch which enables jumbo frames on tulip based boards. It makes it possible to set an MTU of up to 2025 bytes. However, testing against an NE3200 board; /archives/netdev/2003-12/msg00162.html (10,015 bytes)
4. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Tue, 9 Dec 2003 22:32:18 +0100; That sounds like a good idea. I'll do that. I tried to find a good place in the private structure to add the rx_buf_sz field. By good, I mean using the cache efficiently. Any comments about that? I h; /archives/netdev/2003-12/msg00164.html (10,271 bytes)
5. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 09 Dec 2003 14:38:01 -0800; return (mtu - VLAN_HLEN); return (mtu); } and int foobar_change_mtu (struct net_device *dev, int mtu) { mtu = vlan_adjust_mtu (mtu); /* check hardware limits. */ ... dev->mtu = mtu; return (0); } ? B; /archives/netdev/2003-12/msg00166.html (10,166 bytes)
6. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: "Rask Ingemann Lambertsen" <rask@xxxxxxxxxx>; Date: Wed, 10 Dec 2003 00:40:02 +0100; You could use something like if (dev->priv_flags & IFF_802_1Q_VLAN) return (mtu - VLAN_HLEN); else return (mtu); but then you have a problem if the MTU is set to the maximum with VLAN disabled and so; /archives/netdev/2003-12/msg00167.html (10,248 bytes)
7. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Tue, 09 Dec 2003 11:45:42 -0500; Two questions and a comment... Would you split this into two patches? The first simply adds, and uses, Have you looked at Donald Becker's changes to tulip.c? He went through most of his drivers and m; /archives/netdev/2003-12/msg00168.html (9,267 bytes)
8. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Sat, 13 Dec 2003 18:29:28 +0100; The first patch is attached to this message. I'm not happy with the second part yet because it is too hackish and I would prefer to have a look at the tulip documentation first. I've just tested Beck; /archives/netdev/2003-12/msg00228.html (9,794 bytes)
9. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Fri, 19 Dec 2003 15:32:42 +0100; Further, why is it not the responsibility of vconfig to ensure that the MTU of the VLAN device is 4 lower than that of the underlying, "bare" Ethernet device? -- Regards, Rask Ingemann Lambertsen; /archives/netdev/2003-12/msg00296.html (9,515 bytes)
10. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: d S. Miller" <davem@xxxxxxxxxx>; Date: Fri, 19 Dec 2003 22:22:34 -0800; Rask Ingemann Lambertsen wrote: On Wed, Dec 10, 2003 at 12:40:02AM +0100, Rask Ingemann Lambertsen wrote: That said, even checking CONFIG_VLAN_8021Q is probably flawed too, because ideally, even when; /archives/netdev/2003-12/msg00307.html (10,763 bytes)
11. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Thu, 27 May 2004 12:29:39 -0700; Whatever became of this? For what it's worth, I have been using a patch originally by Ben McKeegan that seems to work fine. But, I'd be happy for either of the patches to go in so long as we can fina; /archives/netdev/2004-05/msg00928.html (20,821 bytes)
12. [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Tue, 9 Dec 2003 16:06:35 +0100; Attached is a patch which enables jumbo frames on tulip based boards. It makes it possible to set an MTU of up to 2025 bytes. However, testing against an NE3200 board using 10base-2 shows assorted pr; /archives/netdev/2003-12/msg00557.html (8,460 bytes)
13. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 09 Dec 2003 09:28:23 -0800; Rask Ingemann Lambertsen wrote: Attached is a patch which enables jumbo frames on tulip based boards. It makes it possible to set an MTU of up to 2025 bytes. However, testing against an NE3200 board; /archives/netdev/2003-12/msg00561.html (10,035 bytes)
14. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Tue, 9 Dec 2003 22:32:18 +0100; That sounds like a good idea. I'll do that. I tried to find a good place in the private structure to add the rx_buf_sz field. By good, I mean using the cache efficiently. Any comments about that? I h; /archives/netdev/2003-12/msg00563.html (10,390 bytes)
15. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 09 Dec 2003 14:38:01 -0800; What do you propose? Do we need something like int vlan_adjust_mtu (int mtu) { return (mtu - VLAN_HLEN); return (mtu); } and int foobar_change_mtu (struct net_device *dev, int mtu) { mtu = vlan_adju; /archives/netdev/2003-12/msg00565.html (10,080 bytes)
16. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: "Rask Ingemann Lambertsen" <rask@xxxxxxxxxx>; Date: Wed, 10 Dec 2003 00:40:02 +0100; You could use something like if (dev->priv_flags & IFF_802_1Q_VLAN) return (mtu - VLAN_HLEN); else return (mtu); but then you have a problem if the MTU is set to the maximum with VLAN disabled and so; /archives/netdev/2003-12/msg00566.html (10,376 bytes)
17. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Tue, 09 Dec 2003 11:45:42 -0500; Two questions and a comment... Would you split this into two patches? The first simply adds, and uses, Have you looked at Donald Becker's changes to tulip.c? He went through most of his drivers and m; /archives/netdev/2003-12/msg00567.html (9,329 bytes)
18. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Sat, 13 Dec 2003 18:29:28 +0100; The first patch is attached to this message. I'm not happy with the second part yet because it is too hackish and I would prefer to have a look at the tulip documentation first. I've just tested Beck; /archives/netdev/2003-12/msg00627.html (9,913 bytes)
19. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Rask Ingemann Lambertsen <rask@xxxxxxxxxx>; Date: Fri, 19 Dec 2003 15:32:42 +0100; Further, why is it not the responsibility of vconfig to ensure that the MTU of the VLAN device is 4 lower than that of the underlying, "bare" Ethernet device? -- Regards, Rask Ingemann Lambertsen; /archives/netdev/2003-12/msg00695.html (9,717 bytes)
20. Re: [EXPERIMENTAL PATCH] 2.4 tulip jumbo frames (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Fri, 19 Dec 2003 22:22:34 -0800; That said, even checking CONFIG_VLAN_8021Q is probably flawed too, because ideally, even when building a kernel without VLAN support, you should be able to use the bridging support in a VLAN environm; /archives/netdev/2003-12/msg00706.html (10,931 bytes)

Current List: 1 - 20
Page: [1]