Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this
function)
drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported
only once
drivers/net/spider_net.c:818: error: for each function it appears in.)
drivers/net/spider_net.c: In function 'spider_net_xmit':
drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this
function)
drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this
function)
drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this
function)
make[2]: *** [drivers/net/spider_net.o] Error 1
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/spider_net.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
--- a/drivers/net/spider_net.c 2007-09-22 06:26:39.0 +0530
+++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.0 +0530
@@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr;
struct spider_net_hw_descr *hwdescr;
@@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
spider_net_release_tx_chain(card, 0);
if (spider_net_prepare_tx_descr(card, skb) != 0) {
- dev->stats.tx_dropped++;
+ netdev->stats.tx_dropped++;
netif_stop_queue(netdev);
return NETDEV_TX_BUSY;
}
@@ -979,16 +980,12 @@ static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider_net_card *card)
{
- struct spider_net_hw_descr *hwdescr= descr->hwdescr;
- struct sk_buff *skb;
- struct net_device *netdev;
- u32 data_status, data_error;
-
- data_status = hwdescr->data_status;
- data_error = hwdescr->data_error;
- netdev = card->netdev;
+ struct spider_net_hw_descr *hwdescr = descr->hwdescr;
+ struct sk_buff *skb = descr->skb;
+ struct net_device *netdev = card->netdev;
+ u32 data_status = hwdescr->data_status;
+ u32 data_error = hwdescr->data_error;
- skb = descr->skb;
skb_put(skb, hwdescr->valid_size);
/* the card seems to add 2 bytes of junk in front
@@ -1015,8 +1012,8 @@ spider_net_pass_skb_up(struct spider_net
}
/* update netdevice statistics */
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += skb->len;
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += skb->len;
/* pass skb up to stack */
netif_receive_skb(skb);
@@ -1184,6 +1181,7 @@ static int spider_net_resync_tail_ptr(st
static int
spider_net_decode_one_descr(struct spider_net_card *card)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *descr = chain->tail;
struct spider_net_hw_descr *hwdescr = descr->hwdescr;
@@ -1210,7 +1208,7 @@ spider_net_decode_one_descr(struct spide
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
(status == SPIDER_NET_DESCR_FORCE_END) ) {
if (netif_msg_rx_err(card))
- dev_err(&card->netdev->dev,
+ dev_err(&dev->dev,
"dropping RX descriptor with state %d\n",
status);
dev->stats.rx_dropped++;
goto bad_desc;
-
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: Distributed storage. Security attributes and ducumentation update.
Hi! > I'm pleased to announce third release of the distributed storage > subsystem, which allows to form a storage on top of remote and local > nodes, which in turn can be exported to another storage as a node to > form tree-like storages. How is this different from raid0/1 over nbd? Or raid0/1 over ata-over-ethernet? > +| DST storate ---| storage? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 18:03:55 +0100 > > > Do patches look ok to you? > > I'm travelling so I haven't looked closely yet :-) > > Michael can take a look and I'll try to do so as well > tonight. > I've already reviewed the earlier versions of the patch and have made some suggestions. This latest one looks ok to me and tested ok. I'll follow up later with another patch to remove all the zeros in other firmware sections, and to remove the gzip headers completely. Acked-by: Michael Chan <[EMAIL PROTECTED]> - 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] note that NETIF_F_LLTX is deprecated (was: [kvm-devel][PATCH 3/6] virtio net driver)
On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote:
>
> I suggest to document that LLTX is deprecated.
>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
This looks good to me.
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 1/2] bnx2: factor out gzip unpacker
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote: > > According to an earlier thread, dgrs was never really maintained, > > written for hardware that was never really distributed widely, and very > > likely hasn't had users in years... if ever. > > > > If that picture is accurate (it's a story I was told), then I am > > definitely queueing up a deletion patch. > > I think thats sensible. If someone whines it can be put back but I really > don't think anyone will nobody did yet, please yell if you need a rebased patch. -- maks - 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 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko wrote: On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a "install modules", we can also add "install firmware". Install where? I boot my machine over NFS, and it has no hard drive. Special cases already fail when using distro-linked targets like "make install." Jeff - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: > > On Fri, 21 Sep 2007, Denys Vlasenko wrote: > > > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > >> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > >> > >>> I plan to use gzip compression on following drivers' firmware, > >>> if patches will be accepted: > >>> > >>>textdata bss dec hex filename > >>> 17653 109968 240 127861 1f375 drivers/net/acenic.o > >>>6628 120448 4 127080 1f068 drivers/net/dgrs.o > >>> ^^ > >> > >> Should this be redone to use the existing firmware loading framework to > >> load the firmware instead? > > > > Not in every case. > > > > For example, bnx2 maintainer says that driver and > > firmware are closely tied for his driver. IOW: you upgrade kernel > > and your NIC is not working anymore. > > Firmware may come with a kernel. We have a "install modules", we can also > add "install firmware". Install where? I boot my machine over NFS, and it has no hard drive. > > Another argument is to make kernel be able to bring up NICs > > without needing firmware images in initramfs/initrd/hard drive. > > It is not possible to bring up things like FC or WiFi without firmware, > what special is in classic NICs? Nothing. It is just not (yet?) decreed from The Very Top that all and every firmware image should be loaded using request_firmware(). Also people may want to gzip something else than firmware. -- vda - 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: e1000 driver and samba
Bruce Cole <[EMAIL PROTECTED]> : > Francois Romieu wrote: [...] > >Can you be more specific ? > > > Yes per the reference I gave: > http://www.spinics.net/lists/netdev/msg40384.html [...] Ok, I wondered if you had found something between the start_xmit and the Tx completion code. [...] > I could probably help fix the underlying problem but I didn't > receive any response to my post quoted above. I have submitted the smallest workaround to Jeff. It is not necessarily the best wrt performance but this part is not trivial to arbitrate. -- 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 1/2] bnx2: factor out gzip unpacker
> According to an earlier thread, dgrs was never really maintained, > written for hardware that was never really distributed widely, and very > likely hasn't had users in years... if ever. > > If that picture is accurate (it's a story I was told), then I am > definitely queueing up a deletion patch. I think thats sensible. If someone whines it can be put back but I really don't think anyone will - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 21:13, Andi Kleen wrote: > Denys Vlasenko <[EMAIL PROTECTED]> writes: > > > > I plan to use gzip compression on following drivers' firmware, > > if patches will be accepted: > > > >textdata bss dec hex filename > > 17653 109968 240 127861 1f375 drivers/net/acenic.o > >6628 120448 4 127080 1f068 drivers/net/dgrs.o > > ^^ > > Just change the makefiles to always install gzip'ed modules > modutils knows how to unzip them on the fly. But I compile net/* into bzImage. I like netbooting :) -- vda - 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 1/2] bnx2: factor out gzip unpacker
Alan Cox wrote: For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null According to an earlier thread, dgrs was never really maintained, written for hardware that was never really distributed widely, and very likely hasn't had users in years... if ever. If that picture is accurate (it's a story I was told), then I am definitely queueing up a deletion patch. Jeff - 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: ?^?H?G Re: [linux-usb-devel] Please pull 'ssb-drivers' branch of wireless-2.6 -- aln.
On Fri, Sep 21, 2007 at 10:58:37AM +0800, [EMAIL PROTECTED] wrote: > > Hi Greh, hm, I don't know of anyone by that name :) You might not want to take over a totally different thread for your question, it doesn't make much sense that way... > I donot know how to ask question to u, so use this reply. > We are focusing on 2.4.20 to make use of usbserial driver work for > Notevel U740, but it would crash after long run, seem the Interrupt > stopped, and can't send down, stoped at generic_write func call alwways > return with busy. > And could you tell us some idea or how to debug the code, when we > open the usb debug, it would crash quickly, since the printk have huge > messages, is there good idea to debug or how to go? No one supports 2.4.20 anymore, sorry. I suggest you move to the 2.6 kernel tree instead. good luck, greg k-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
Re: [stable] [PATCH] cfg80211: fix initialisation if built-in
On Fri, 2007-09-21 at 15:02 -0700, Greg KH wrote: > When this goes into Linus's tree, please resend it to the > [EMAIL PROTECTED] address so we can add it to our queue. It's on the way, sitting in net-2.6.24 right now but I don't know whether it's scheduled for .23. I'm no longer sure if it really matters for -stable since we have no drivers there so typically drivers build as out-of-tree modules and the issue doesn't matter. johannes signature.asc Description: This is a digitally signed message part
Re: e1000 driver and samba
Francois Romieu wrote: Bruce Cole <[EMAIL PROTECTED]> : If you look for it on the Realtek cards, there had been sporadic Nissues up to late 2005. The solution posted universally was 'change card'. Yes, that *was* the common recommendation. There was no such thing as a universal solution to sporadic issues. I made no such claim. I do claim the realtek samba et all issues are not sporadic however. In fact the common problem is readily reproducible as has been shown. [...] I suspect the root problem is the driver isn't properly locking the TX queue. Can you be more specific ? Yes per the reference I gave: http://www.spinics.net/lists/netdev/msg40384.html "Now since this change heals the TX queue stall, it would seem that the real underlying problem involves a race condition with enqueueing to the TX queue while the controller is processing the queue. The ultimate fix for that I bet is either to address locking at TX enqueue time, or there is a controller bug. Any clarification from realtek on the necessary processing for the NPQ bit, or a known controller problem? PS: I've also received private email that this problem pertains to video streaming (to a Kiss DVD player) not just samba or X11 traffic. Basically most all high-level TCP based protocols are affected it seems. This serious performance problem should be considered to impact a lot more than just samba users." I could probably help fix the underlying problem but I didn't receive any response to my post quoted above. - 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: change the way e1000 is handling short VLAN frames
On 9/21/07, jamal <[EMAIL PROTECTED]> wrote: > On Fri, 2007-21-09 at 14:34 -0700, Kok, Auke wrote: > > > I never saw any bugreports about e1000 not being able to accept vlan packets > > because of this, so I'm quite certain it works OK, feel free to find me a > > case > > where this isn't so :) > > If you tell me it can be done on the rx, i will take your word for it;-> > Emil can certainly verify it. > The tx you certainly have issues - Look at one of the suggestions from > Chris, i think it is resolvable. I'd say that devices that can't receive 64 bytes VLAN tagged frames have an issue, but for the sake of interoperability and solving Emil's problem I'm willing to discuss how a change to e1000 would work ;-) The simplest option is to add software small frame padding all the time. It won't catch software tagged frames if they were generated somehow, but should fix the hardware tagged ones to be 68 bytes on the wire. If you were worried about software tagged frames then replacing ETH_ZLEN with VLAN_ETH_ZLEN would pad all frames, VLAN or not, to 68 bytes. Emil, this patch will probably do what you want. diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 4a22595..34e3d18 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -3284,6 +3284,9 @@ e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) return NETDEV_TX_OK; } + if (skb_padto(skb, ETH_ZLEN)) + return NETDEV_TX_OK; + /* 82571 and newer doesn't need the workaround that limited descriptor * length to 4kB */ if (adapter->hw.mac_type >= e1000_82571) - 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: [stable] [PATCH] cfg80211: fix initialisation if built-in
On Mon, Sep 10, 2007 at 01:44:45PM +0200, Johannes Berg wrote: > When cfg80211 is built into the kernel it needs to init earlier > so that device registrations are run after it has initialised. > > Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> When this goes into Linus's tree, please resend it to the [EMAIL PROTECTED] address so we can add it to our queue. thanks, greg k-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
Re: e1000 driver and samba
Bruce Cole <[EMAIL PROTECTED]> : > >If you look for it on the Realtek cards, there had been sporadic > >Nissues up to late 2005. The solution posted universally was 'change > >card'. > > Yes, that *was* the common recommendation. There was no such thing as a universal solution to sporadic issues. [...] > I suspect the root problem is the driver isn't properly locking > the TX queue. Can you be more specific ? -- 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 14:34 -0700, Kok, Auke wrote: > I never saw any bugreports about e1000 not being able to accept vlan packets > because of this, so I'm quite certain it works OK, feel free to find me a case > where this isn't so :) If you tell me it can be done on the rx, i will take your word for it;-> Emil can certainly verify it. The tx you certainly have issues - Look at one of the suggestions from Chris, i think it is resolvable. cheers, jamal - 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 14:27 -0700, Chris Leech wrote: > > Inserting the VLAN tag in software will not change the behavior in the > way you want anyway, short frames will still be padded to 64 bytes. > You'd have to do short packet padding in software to 68 bytes. Or do > software padding to 64 bytes and let the hardware insert the VLAN tag > after. I like the second one because it could be done totaly in the driver and would resolve the problem IMO. All we need after is an ethtool knob to select between 64B or 68B txmit. cheers, jamal - 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: change the way e1000 is handling short VLAN frames
jamal wrote: >> AFAIK the RX side is fully covered > > so you can handle both 64B and 68B? I never saw any bugreports about e1000 not being able to accept vlan packets because of this, so I'm quite certain it works OK, feel free to find me a case where this isn't so :) Auke - 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: change the way e1000 is handling short VLAN frames
On 9/21/07, jamal <[EMAIL PROTECTED]> wrote: > On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote: > > > I just re-read the spec, and a bridge *may* pad up to 68, but it is not > > required. > > On page 166, it says equipment must be able to handle 64 byte minimums. > > > > See page 22 (section 7.2) of this document: > > > > http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf > > > > Also, page 63, 165, 166 > > Thanks for the enlightnment. > Do we need an ethtool interface to turn off hardware accelerated vlans? > Jesse is indicating that the intel hardware can only handle the MUST but > not the SHOULD of the spec. > Actually a more basic question: Can you select one or the other mode in > the software based vlans? Inserting the VLAN tag in software will not change the behavior in the way you want anyway, short frames will still be padded to 64 bytes. You'd have to do short packet padding in software to 68 bytes. Or do software padding to 64 bytes and let the hardware insert the VLAN tag after. Chris - 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 14:18 -0700, Ben Greear wrote: > As for using the software stack, I don't think we are padding to 68 in > the soft vlans either... Should be much easier than changing firmware or an ASIC. > It would be nice to have an ethtool to turn off hw vlans for other reasons, > like sniffing vlan tags, at least... Hrm, no hardware out there will pass on tags to the stack as metadata? On Fri, 2007-21-09 at 14:21 -0700, Kok, Auke wrote: > I don't actually see the "SHOULD" part you are referring to. the "optional" part;-> MAY? > AFAIK the RX side is fully covered so you can handle both 64B and 68B? > and only on TX the hardware sends out 64b padded vlan packets, which > is permitted. The spec never says that it is required to send out 68b padded > vlan > packets - only permits either choice. The CISCO i pointed to seems to be only capable of 68B. So if the CISCO sends to you, it would work, but you sending to the CISCO or to Emil's CMTS you have challenges, no? cheers, jamal - 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: change the way e1000 is handling short VLAN frames
jamal wrote: > On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote: > >> I just re-read the spec, and a bridge *may* pad up to 68, but it is not >> required. >> On page 166, it says equipment must be able to handle 64 byte minimums. >> >> See page 22 (section 7.2) of this document: >> >> http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf >> >> Also, page 63, 165, 166 > > Thanks for the enlightnment. > Do we need an ethtool interface to turn off hardware accelerated vlans? > Jesse is indicating that the intel hardware can only handle the MUST but > not the SHOULD of the spec. I don't actually see the "SHOULD" part you are referring to. AFAIK the RX side is fully covered and only on TX the hardware sends out 64b padded vlan packets, which is permitted. The spec never says that it is required to send out 68b padded vlan packets - only permits either choice. Auke - 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: change the way e1000 is handling short VLAN frames
jamal wrote: On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote: I just re-read the spec, and a bridge *may* pad up to 68, but it is not required. On page 166, it says equipment must be able to handle 64 byte minimums. See page 22 (section 7.2) of this document: http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf Also, page 63, 165, 166 Thanks for the enlightnment. Do we need an ethtool interface to turn off hardware accelerated vlans? Jesse is indicating that the intel hardware can only handle the MUST but not the SHOULD of the spec. Actually a more basic question: Can you select one or the other mode in the software based vlans? It's not even clear to me that it's a Should..more like a 'May', for what thats worth. As for using the software stack, I don't think we are padding to 68 in the soft vlans either... It would be nice to have an ethtool to turn off hw vlans for other reasons, like sniffing vlan tags, at least... You cannot select hw v/s soft vlans...the code always uses hw-accel if it's available, as far as I know. Thanks, Ben cheers, jamal -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote: > I just re-read the spec, and a bridge *may* pad up to 68, but it is not > required. > On page 166, it says equipment must be able to handle 64 byte minimums. > > See page 22 (section 7.2) of this document: > > http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf > > Also, page 63, 165, 166 Thanks for the enlightnment. Do we need an ethtool interface to turn off hardware accelerated vlans? Jesse is indicating that the intel hardware can only handle the MUST but not the SHOULD of the spec. Actually a more basic question: Can you select one or the other mode in the software based vlans? cheers, jamal - 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 3/7] CAN: Add raw protocol
Patrick McHardy <[EMAIL PROTECTED]> writes: > Urs Thuermann wrote: > > +config CAN_RAW_USER > > + bool "Allow non-root users to access Raw CAN Protocol sockets" > > > If you plan to remove this option, it should happen before merging > since it affects userspace visible behaviour. We have discussed this and have come to the conclusion that we should remove permission checks completely, i.e. any user can open any CAN socket (raw, bcm, or whatever will be implemented in the future). This is because CAN is a pure broadcast network with no addresses. CAN frames can't be directed to only one machine or a group or to only one process (say one port). There is no communication between only two (or some number) of stations which must be protected from other stations. On the other hand, requiring a process to have CAP_NET_RAW to open a CAN socket would mean that such process would also be able to sniff on your ethernet or WLAN interfaces, which one probably wouldn't want. We have added that check when we still allowed the CAN raw socket to bind to any interface and we didn't want an unprivileged process to be able to read all e.g. TCP/IP traffic. Now binding is restricted to ARPHRD_CAN interfaces. But even without this restriction the check is not necessary, since all CAN sockets can only receive and send ETH_P_CAN packets. So even if there would be an encapsulation of CAN frames over ethernet or some other type of network, a normal user process opening a CAN socket would only be able to read/write CAN traffic, which should be OK without any special capability. So what do you think about this? urs - 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 1/2] bnx2: factor out gzip unpacker
> For example, bnx2 maintainer says that driver and > firmware are closely tied for his driver. IOW: you upgrade kernel > and your NIC is not working anymore. > > Another argument is to make kernel be able to bring up NICs > without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null Alan - 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 1/2] bnx2: factor out gzip unpacker
> Just change the makefiles to always install gzip'ed modules > modutils knows how to unzip them on the fly. But that leaves the uncompressed firmware blobs in .data that ends up in unswappable kernel memory. - R. - 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 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko <[EMAIL PROTECTED]> writes: > > I plan to use gzip compression on following drivers' firmware, > if patches will be accepted: > >textdata bss dec hex filename > 17653 109968 240 127861 1f375 drivers/net/acenic.o >6628 120448 4 127080 1f068 drivers/net/dgrs.o > ^^ Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. That will catch all the firmware and all the other code too. -Andi - 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] sb1250-mac: Driver model & phylib update
On Fri, 21 Sep 2007 12:52:10 +0100 (BST) "Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote: > A driver model and phylib update. akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1 1013 files changed, 187667 insertions(+), 23587 deletions(-) Sorry, but raising networking patches against Linus's crufty old mainline tree just isn't viable at present. - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a "install modules", we can also add "install firmware". Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. It is not possible to bring up things like FC or WiFi without firmware, what special is in classic NICs? Best regards, Krzysztof Olędzki
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said: > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > > Should this be redone to use the existing firmware loading framework to > > load the firmware instead? > > Not in every case. > > For example, bnx2 maintainer says that driver and > firmware are closely tied for his driver. IOW: you upgrade kernel > and your NIC is not working anymore. > > Another argument is to make kernel be able to bring up NICs > without needing firmware images in initramfs/initrd/hard drive. OK, I can live with "considered and decided against". :) pgpiAVb5VJZHz.pgp Description: PGP signature
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > > > I plan to use gzip compression on following drivers' firmware, > > if patches will be accepted: > > > >textdata bss dec hex filename > > 17653 109968 240 127861 1f375 drivers/net/acenic.o > >6628 120448 4 127080 1f068 drivers/net/dgrs.o > > ^^ > > Should this be redone to use the existing firmware loading framework to > load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. -- vda - 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] PHYLIB: IRQ event workqueue handling fixes
On Fri, 21 Sep 2007 13:51:12 +0100 (BST) "Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote: > On Thu, 20 Sep 2007, Andrew Morton wrote: > > > You always put boring, crappy, insufficient text in the for-the-changelog > > section and interesting, useful, sufficient text in the > > not-for-the-changelog > > section. > > I'll swap the sections in the future then. ;-) Frankly I was not sure > whether the changelog was happy about being fed with lengthy explanations > and it has not spoken out. I think it's worth putting plenty of details in the changelog: it's compressed on-disk and on-the-wire and is overall pretty cheap. If people don't actually seek the information out, it has close to zero impact on them. But on those occasions when people _do_ seek the information out (and it can be years later) then they want every drop of information they can get. Numerous times I've gone back to the 2.5.x mm/ changelogs to work out what on earth we were thinking when we did something, and it has proved quite useful in explaining the existing code, or in suggesting possible problems which we had forgotten about by 2007. otoh, you can get a lot of handy info by googling for strategic parts of the kernel code, or by googling snippets of the existing-but-short changelog. For example, this patch: google for "Keep track of disable_irq_nosync() invocations" and voila. Perhaps we don't need changelogs at all ;) - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > I plan to use gzip compression on following drivers' firmware, > if patches will be accepted: > >textdata bss dec hex filename > 17653 109968 240 127861 1f375 drivers/net/acenic.o >6628 120448 4 127080 1f068 drivers/net/dgrs.o > ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? pgp8MqMgJq48R.pgp Description: PGP signature
Re: e1000 driver and samba
L F wrote: Aha. This doesn't seem to be in mr. Romieu's patch above: should it go in on top of that? His newer 0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch does the same thing as the older quoted version, and is also included in the roll-up patch he pointed you to. I agree re. performance, and don't want to clutter the thread realtek issues. I just wanted to clarify this particular realtek-samba issue in case it's relevant. For a long time folks suspected similar culprits (bad cable, half duplex, etc.) when it was the driver. Perhaps you should try doing a ping flood between server&client during your test. That healed the problem by keeping the queue busy in the realtek case. - 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
[updated PATCH] forcedeth: power down phy when interface is down
On 9/19/07, Ayaz Abdulla <[EMAIL PROTECTED]> wrote: > It seems that you are powering down the phy even if WOL is enabled. Right; I've updated the patch to skip powering down the phy when wol is enabled. > Secondly, can you powerdown the phy at the same time you start > performing autoneg restart? This seems to work fine with a BCM5461S phy; it would be worth testing with other phys to be sure. --Ed forcedeth-phy-power-down.patch Description: Binary data
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Patrick McHardy <[EMAIL PROTECTED]> writes: > You drop the module reference again when leaving this function. > So sock->ops might contain a stale pointer if the module is > unloaded after this. You need to either keep the module reference > while the socket is alive or remove stale references when > unregistering the protocol. I don't think that can happen. Before we drop the module reference we call sk_alloc() which gets another module reference via its cp->prot argument. If sk_alloc() fails we return with error from can_create() I assume sock->ops won't be used after that. urs - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 18:49, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 18:03:55 +0100 > > > Do patches look ok to you? > > I'm travelling so I haven't looked closely yet :-) > > Michael can take a look and I'll try to do so as well > tonight. Good. I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ -- vda - 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 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko <[EMAIL PROTECTED]> Date: Fri, 21 Sep 2007 18:03:55 +0100 > Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. - 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 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets
On Thu, 20 Sep 2007, Nagendra Tomar wrote: > > That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the > > ability to write, and it is not meant as to signal every time a packet > > (skb) is sent on the wire (and the buffer released). > > Aren't they both the same ? Everytime an incoming ACK frees up a buffer > from the retransmit queue, the writability condition is freshly asserted, > much the same way as the readability condition is asserted everytime a > new data is queued in the socket receive queue (irrespective of > whether there was data already waiting to be read in the receive queue). > > This difference in meaning of POLLOUT only arises in the ET case, which was > not what traditional Unix poll referred to. Again, events here are "readability" and "writeability" and the fact that the lower network layer freed a buffer is not, per se, an event (unless before, "writeability" was tested and reported as unavailable). In you case the solution looks pretty simple. Just create appropriately sized buffers, split the single sendfile into multiple buffer-sized ones, and recycle the buffer once each of them completes. - Davide - 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: change the way e1000 is handling short VLAN frames
Emil Micek wrote: > What is the right behaviour according to specification? In iee802.3, > minFrameSize is 64bytes. I've never seen any document which'd say that > VLAN frames should be 68 bytes minimum. e1000 only hardware pads to 64 bytes, but if you use the vlan module and turn off the hardware assistance of inserting tags, by unsetting NETIF_F_HW_VLAN_* in netdev->features. the software insertion sounds like it should work for you at the cost of higher CPU. >>> I'd like to change it so it first pads the frame to 64 B and >>> appends the VLAN tag afterwards, so the resulting VLAN frame would >>> be 68 bytes minimum. at least for e1000 this isn't possible in the driver, while still doing hardware vlan insertion. Jesse - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 17:14, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 12:01:24 +0100 > > > Hi Jeff, > > BNX2 and TG3 patches goes through Michael Chan and myself, > and I usually merge them in instead of Jeff. Didn't know that, sorry. Do patches look ok to you? -- vda - 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 2/7] CAN: Add PF_CAN core module
On Fri, 2007-09-21 at 12:35 +0200, Urs Thuermann wrote:
> I didn't find a way with gcc-2.95 to make the format
> string a separate macro argument (which I also wanted).
The old 2.x GCC workaround was to use
#define DBG(fmt, arg) printk(fmt , ## arg)
adding a space before the last comma.
> I use "do { ... } while(0)" only for statements, not for expressions.
> But I could have used the && instead of ?: operator. I don't think
> the "do { ... } while(0)" looks nicer or has any other advantage.
It's more linux convention.
It allows the macro to be used in if-else constructs.
> > > void can_debug_cframe(const char *msg, struct can_frame *cf, ...)
> > This prototype looks backwards to me.
> You mean the order or `msg' and `cf'?
Yes, I believe the can_frame* should be the first argument.
> Ah, I didn't know print_hex_dump(). That looks nicer. But as Thomas
> mentioned, we shouldn't convert these functions into macros.
The first print_hex_dump should actually be print_hex_dump_bytes.
I was typing what I hoped was a readable example.
I hope you do convert to functions, but not to inline functions.
cheers, Joe
-
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] e1000e: Do not allow requeue of freed skb
From: Krishna Kumar <[EMAIL PROTECTED]> Returning BUSY will make qdisc_restart enqueue the skb which was already freed. The bad skb was correctly freed and we should return NETDEV_TX_OK. First spotted by Jeff Garzik on 08/13/07. Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000e/netdev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c index 372da46..03f7472 100644 --- a/drivers/net/e1000e/netdev.c +++ b/drivers/net/e1000e/netdev.c @@ -3537,7 +3537,7 @@ static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) /* handle pci_map_single() error in e1000_tx_map */ dev_kfree_skb_any(skb); spin_unlock_irqrestore(&adapter->tx_queue_lock, irq_flags); - return NETDEV_TX_BUSY; + return NETDEV_TX_OK; } e1000_tx_queue(adapter, tx_flags, count); - 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: net-2.6.24 - build failure
On Thursday 20 September 2007 00:17:12 David Miller wrote: > From: Joe Perches <[EMAIL PROTECTED]> > Date: Wed, 19 Sep 2007 14:53:22 -0700 > > > drivers/net/wireless/b43legacy/built-in.o: In function `tsf_read_file': > > drivers/net/wireless/b43legacy/debugfs.c:80: multiple definition of > > `tsf_read_file' > > Can one of the wireless folks fix b43legacy to not use the same > global variable and function names as the b43 driver? Fixes are already submitted. This was only an accident (forgot static). -- Greetings Michael. - 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 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko <[EMAIL PROTECTED]> Date: Fri, 21 Sep 2007 12:01:24 +0100 > Hi Jeff, BNX2 and TG3 patches goes through Michael Chan and myself, and I usually merge them in instead of Jeff. - 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
want same order in /sys/class/net/eth as /sys/bus/pci/devices
I'd like to see the same order of devices in /sys/class/net/eth* as in /sys/bus/pci/devices. This would make administration easier. On Fedora 8 tests, the order I see is reversed: http://bugzilla.redhat.com/show_bug.cgi?id=291431 Perhaps the reversal is a result of the alias order listed in /etc/modprobe.conf. But the alias order was obtained from some source. Was the first reversal due to a user-space program (such as the anaconda installer), or due to something within the kernel? -- John Reiser, [EMAIL PROTECTED] - 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: SFQ qdisc crashes with limit of 2 packets
Hello!
Remove artificial limitation for sfq queue limit.
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the whole range of hash values.
Switched to Jenkins' hash.
Signed-off-by: Alexey Kuznetsov <[EMAIL PROTECTED]>
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 3a23e30..b542c87 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -95,7 +96,7 @@ struct sfq_sched_data
/* Variables */
struct timer_list perturb_timer;
- int perturbation;
+ u32 perturbation;
sfq_index tail; /* Index of current slot in round */
sfq_index max_depth; /* Maximal depth */
@@ -109,12 +110,7 @@ struct sfq_sched_data
static __inline__ unsigned sfq_fold_hash(struct sfq_sched_data *q, u32 h, u32
h1)
{
- int pert = q->perturbation;
-
- /* Have we any rotation primitives? If not, WHY? */
- h ^= (h1<>(0x1F - pert));
- h ^= h>>10;
- return h & 0x3FF;
+ return jhash_2words(h, h1, q->perturbation) & (SFQ_HASH_DIVISOR - 1);
}
static unsigned sfq_hash(struct sfq_sched_data *q, struct sk_buff *skb)
@@ -256,6 +252,13 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q->ht[hash] = x = q->dep[SFQ_DEPTH].next;
q->hash[x] = hash;
}
+ /* If selected queue has length q->limit, this means that
+* all another queues are empty and that we do simple tail drop,
+* i.e. drop _this_ packet.
+*/
+ if (q->qs[x].qlen >= q->limit)
+ return qdisc_drop(skb, sch);
+
sch->qstats.backlog += skb->len;
__skb_queue_tail(&q->qs[x], skb);
sfq_inc(q, x);
@@ -294,6 +297,19 @@ sfq_requeue(struct sk_buff *skb, struct Qdisc* sch)
}
sch->qstats.backlog += skb->len;
__skb_queue_head(&q->qs[x], skb);
+ /* If selected queue has length q->limit+1, this means that
+* all another queues are empty and we do simple tail drop.
+* This packet is still requeued at head of queue, tail packet
+* is dropped.
+*/
+ if (q->qs[x].qlen > q->limit) {
+ skb = q->qs[x].prev;
+ __skb_unlink(skb, &q->qs[x]);
+ sch->qstats.drops++;
+ sch->qstats.backlog -= skb->len;
+ kfree_skb(skb);
+ return NET_XMIT_CN;
+ }
sfq_inc(q, x);
if (q->qs[x].qlen == 1) { /* The flow is new */
if (q->tail == SFQ_DEPTH) { /* It is the first flow */
@@ -370,12 +386,10 @@ static void sfq_perturbation(unsigned long arg)
struct Qdisc *sch = (struct Qdisc*)arg;
struct sfq_sched_data *q = qdisc_priv(sch);
- q->perturbation = net_random()&0x1F;
+ get_random_bytes(&q->perturbation, 4);
- if (q->perturb_period) {
- q->perturb_timer.expires = jiffies + q->perturb_period;
- add_timer(&q->perturb_timer);
- }
+ if (q->perturb_period)
+ mod_timer(&q->perturb_timer, jiffies + q->perturb_period);
}
static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
@@ -391,7 +405,7 @@ static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
q->perturb_period = ctl->perturb_period*HZ;
if (ctl->limit)
- q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 2);
+ q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 1);
qlen = sch->q.qlen;
while (sch->q.qlen > q->limit)
@@ -400,8 +414,8 @@ static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
del_timer(&q->perturb_timer);
if (q->perturb_period) {
- q->perturb_timer.expires = jiffies + q->perturb_period;
- add_timer(&q->perturb_timer);
+ mod_timer(&q->perturb_timer, jiffies + q->perturb_period);
+ get_random_bytes(&q->perturbation, 4);
}
sch_tree_unlock(sch);
return 0;
@@ -423,12 +437,13 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
q->dep[i+SFQ_DEPTH].next = i+SFQ_DEPTH;
q->dep[i+SFQ_DEPTH].prev = i+SFQ_DEPTH;
}
- q->limit = SFQ_DEPTH - 2;
+ q->limit = SFQ_DEPTH - 1;
q->max_depth = 0;
q->tail = SFQ_DEPTH;
if (opt == NULL) {
q->quantum = psched_mtu(sch->dev);
q->perturb_period = 0;
+ get_random_bytes(&q->perturbation, 4);
} else {
int err = sfq_change(sch, opt);
if (err)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
Re: change the way e1000 is handling short VLAN frames
jamal wrote: On Fri, 2007-21-09 at 09:37 -0400, jamal wrote: On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote: On Fri, 2007-09-21 at 07:59 -0400, jamal wrote: Which would make it a bug. AFAIK, the minimum VLAN tagged packet going out is 68 bytes. Are you sure about this? This is what i have always seen. If the first email caused confusion - so will this ;-> I have never used e1000 for vlan tagging. My view is that if it emits (instead of 68B) 64B packets with tags then it is buggy and needs to be fixed. Hope that makes sense. I just re-read the spec, and a bridge *may* pad up to 68, but it is not required. On page 166, it says equipment must be able to handle 64 byte minimums. See page 22 (section 7.2) of this document: http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf Also, page 63, 165, 166 Thanks, Ben cheers, jamal - 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 -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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 v2] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.
Evgeniy Polyakov wrote: Hi Steve. On Mon, Sep 17, 2007 at 10:25:04AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote: Does creating the whole new netdevice is a too big overhead, or is it considered bad idea? I think its too big overhead, and pretty invasive on the low level cxgb3 driver. I think having a device in the 'ifconfig -a' after iw_cxgb3 is loaded and devices discovered would be a good thing for the admin. This is the angle Roland suggested. I'm just not sure how to implement it. But if someone could explain how I might create this full netdevice as a pseudo device on top of the real one, maybe I could implement it. Note that non TCP traffic still needs to utilize this interface for ND to work properly with the RDMA core. Just a though - what about allowing secondary addresses with the same address as main one? I.e. change bit of the core code to allow creating aliases with the same address as main device, so that you would be able to create ':iw' alias during rdma device initialization? The problem is that on rdma route/address resolution the rdma core CM uses the routing table to look up which local device to use. So what we need is separate ip subnets for rdma vs non rdma tcp. Also, to avoid the original issue of 4-tuple conflicts, the rdma device _must_ listen on specific local "rdma-only" ip addresses and thus they must be not the same address as that used for native host tcp traffic. Steve. - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
lepton wrote: > My situation is: > The default route device is a e1000 network card that can do TSO. > So the tcp stack will try send big skb to netfilter frame work. > But after rerouting, the packtes will go out from a device that > can not do TSO. the packet is just get dropped.. > > I thinks if we can't get a way to tell tcp stack the sk_route_caps of > the real out device, we can just disable all things for safety. As you already noticed yourself (in private email), this is handled properly in current kernels. - 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] note that NETIF_F_LLTX is deprecated (was: [kvm-devel][PATCH 3/6] virtio net driver)
Am Freitag, 21. September 2007 schrieb Herbert Xu: > Please don't use LLTX in new drivers. We're trying to get rid > of it since it's > > 1) unnecessary; > 2) causes problems with AF_PACKET seeing things twice. I suggest to document that LLTX is deprecated. Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> --- Documentation/networking/netdevices.txt |3 ++- include/linux/netdevice.h |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) Index: linux-2.6/include/linux/netdevice.h === --- linux-2.6.orig/include/linux/netdevice.h +++ linux-2.6/include/linux/netdevice.h @@ -339,7 +339,8 @@ struct net_device #define NETIF_F_HW_VLAN_FILTER 512 /* Receive filtering on VLAN */ #define NETIF_F_VLAN_CHALLENGED1024/* Device cannot handle VLAN packets */ #define NETIF_F_GSO2048/* Enable software GSO. */ -#define NETIF_F_LLTX 4096/* LockLess TX */ +#define NETIF_F_LLTX 4096/* LockLess TX - deprecated. Please */ + /* do not use LLTX in new drivers */ #define NETIF_F_MULTI_QUEUE16384 /* Has multiple TX/RX queues */ /* Segmentation offload features */ Index: linux-2.6/Documentation/networking/netdevices.txt === --- linux-2.6.orig/Documentation/networking/netdevices.txt +++ linux-2.6/Documentation/networking/netdevices.txt @@ -73,7 +73,8 @@ dev->hard_start_xmit: has to lock by itself when needed. It is recommended to use a try lock for this and return NETDEV_TX_LOCKED when the spin lock fails. The locking there should also properly protect against - set_multicast_list. + set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated. + Dont use it for new drivers. Context: Process with BHs disabled or BH (timer), will be called with interrupts disabled by netconsole. - 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: change the way e1000 is handling short VLAN frames
On 9/21/07, jamal <[EMAIL PROTECTED]> wrote: > Hope that makes sense. [cut] > cheers, > jamal Hi all, as far as I understand ieee docs both 64 and 68 approaches are fine... --- Std 802.1Q-2005, 6.5.1 --- On receipt of an M_UNITDATA.request primitive that represents a tagged frame, the implementation is permitted to adopt either of the following approaches with regard to the operation of Transmit Data Encapsulation for frames whose length would, using the procedure as described, be less than 68 octets: a) Use the procedure as described in 6.5.1 of IEEE Std 802.1D. This procedure can result in tagged frames of less than 68 octets (but at least 64 octets) being transmitted; or b) Include additional octets before the FCS field in order for the transmitted frame length for such frames to be 68 octets. This procedure results in a minimum tagged frame length of 68 octets. When a tagged frame of less than 68 octets in length is received on a CSMA/CD LAN segment, and is forwarded as an untagged frame, the provisions of 6.5.1 of IEEE Std 802.1D, result in additional octets being included before the FCS field on transmission in order that the transmitted frame length meets the minimum frame size requirements of 3.2.7 in IEEE Std 802.3. -- and --- Std 802.1Q-2005, C.4.4.1 --- When tagged frames are transmitted by a Bridge on an IEEE Std 802.3 MAC, there are two permissible approaches (7.2), as follows: a) Keep the minimum frame size generated by the Bridge equal to 64 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would be reduced by up to 4 octets when that frame was tagged; b) Adopt a minimum tagged frame length of 68 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would not be adjusted when tagging such frames; equally, if subsequently untagged, no pad adjustment would be necessary before transmission on IEEE 802.3/Ethernet. -- might this problem be solved using a configurable parameter? (default=68) my 0.02 euro Ciao FF - 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: e1000 driver and samba
On 9/20/07, Bruce Cole <[EMAIL PROTECTED]> wrote: > Yes, that *was* the common recommendation. But recently I narrowed down the > realtek performance problem most commonly seen with samba (but also applicable > to other TCP applications), and I also narrowed down the fix as well. > > The current fix involves re-kicking the TX queue after it becomes stuck. > Apparently it becomes stuck due to a contention problem between the driver and > controller. I suspect the root problem is the driver isn't properly locking > the TX queue. It might be worth checking if the queue locking problem exists > in other net drivers as well. Aha. This doesn't seem to be in mr. Romieu's patch above: should it go in on top of that? I ask because with the forementioned patch the newer integrated NICs seem to be recognised correctly and preliminary testing shows no disconnect issues, but performance is nothing to write home about (one of these days I'll get into a rant about samba speed vs. ftp speed, but this is not the time nor place). > Reference: > http://www.spinics.net/lists/netdev/msg40384.html > Bruce Cole LF - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
Yes. My situation is: The default route device is a e1000 network card that can do TSO. So the tcp stack will try send big skb to netfilter frame work. But after rerouting, the packtes will go out from a device that can not do TSO. the packet is just get dropped.. I thinks if we can't get a way to tell tcp stack the sk_route_caps of the real out device, we can just disable all things for safety. On Fri, Sep 21, 2007 at 02:39:58PM +0200, Patrick McHardy wrote: > lepton wrote: > > Yes, you are right. > > What do you think about this: > > For all packets can be sent out, we just disable > > all things in sk_route_caps in ip_route_me_harder > > > Whats the point of doing that? Is rerouting breaking anything for you? - 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: e1000 driver and samba
On 9/19/07, Bill Fink <[EMAIL PROTECTED]> wrote: > Just my personal opinion, but unless you want to do more testing, > since you now seem to have a working setup, I would tend to leave > it the way it is. Quite sensible, yes. Performance even seems to be good - I am getting 40-40MBps reads and 24-26MBps writes - so it'll stay the way it is. > By any chance did you happen to power cycle some equipment in this > process that you didn't previously power cycle during earlier testing > and debugging? If so, perhaps that hardware had somehow gotten into > a funky state, and the power cycling might have cleared it up. Not that I am aware of: one of the first things that I did - and repeated basically every step of the way - was to powercycle the two switches, following the same line of reasoning you did. The clients were turned off every night and turned back on every morning and the WAN Comcast CPE wasn't touched for the duration. The only thing that did change is that in an impetus of efficiency or perhaps desperation I changed that cable too (to CAT6, 3' long), but I can't imagine that would affect the LAN side of operations. Thanks again - to everyone - for the help. I am still puzzled, but at least I am puzzled with a consistent situation. To Mr. Romieu: the patch you provided seems to work, in that 'regular' loads don't trip samba up. I have to check the CRCs, though. > -Bill Luigi Fabio - 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 0/2] David Miller's rbtree patches for 2.6.22.6
On Wed, 19 Sep 2007, Tom Quetchenbach wrote: > Here are a couple of patches against 2.6.22.6. The first one is just > David's patches tweaked for 2.6.22.6, with a couple of minor bugfixes to > get it to compile and not crash. Why did you combine original patches to a single larger one, I think Dave made them separate on purpose. > (I also changed > __tcp_insert_write_queue_tail() to set the fack_count of the new packet > to the fack_count of the tail plus the packet count of the tail, not the > packet count of the new skb, because I think that's how it was intended > to be. Right? I think I noticed similar "off-by-pcount" error when I looked that long time ago, so I guess you're correct. We're only interested in delta of it anyway and add the current skb's pcount to it (which is not fixed until tcp_fragment in sacktag is past). > In the second patch there are a couple of significant changes. One is > (as Baruch suggested) to modify the existing SACK fast path so that we > don't tag packets we've already tagged when we advance by a packet. This solution would still spend extensive amount of time in processing loop, whenever recv_sack_cache fast-path is not taken, that is, e.g. when cumulative ACK after retransmissions arrive or new hole becomes visible (which are not very exceptional events after all :-)). In the cumulative ACK case especially, this processing is very likely _fully_ wasted walking. So there is still room for large improvements. I've made an improved version of the current sacktag walk couple of days ago (it's in a state where it didn't crash but likely very buggy still), I'll post it here soon... Idea is embed recv_sack_cache checking fully into the walking loop. By doing that an previously known work is not duplicated. The patch is currently against non-rbtree stuff but incorporating rb-tree things on top of it should be very trivial and synergy benefits with rbtree should be considerable because non-rbtree has to do "fast walk" skipping for skbs that are under highest_sack which is prone to cache misses. > The other issue is that the cached fack_counts seem to be wrong, because > they're set when we insert into the queue, but tcp_set_tso_segs() is > called later, just before we send, so all the fack_counts are zero. My > solution was to set the fack_count when we advance the send_head. I think it's better solution anyway, since we might have to do reset_fack_counts() in between and there's no need to update past sk_send_head. > Also I > changed tcp_reset_fack_counts() so that it exits when it hits an skb > whose tcp_skb_pcount() is zero Do you mind to explain what's the purpose of that? > or whose fack_count is already correct. > (This really helps when TSO is on, since there's lots of inserting into > the middle of the queue.) Good point. > Please let me know how I can help get this tested and debugged. Most network development happens against latest net-2.6(.x) trees. In addition, there's experimental tcp-2.6 tree but it's currently a bit outdated already (and DaveM is very busy with the phenomenal merge they're doing for 2.6.24 :-) so it's not too likely to be updated very soon). ...Anyway, thanks for your interest in these things. -- i. - 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 2/2] David Miller's rbtree patches for 2.6.22.6
On Wed, 19 Sep 2007, Tom Quetchenbach wrote:
> Patch 2: fixes to fack_counts and enhancement of SACK fast path
...Usually these are not combined in patches but a separate patch per
change.
> diff -ur linux-2.6.22.6-rbtree-davem-fixed/include/net/tcp.h
> linux-2.6.22.6-rbtree-tomq/include/net/tcp.h
> --- linux-2.6.22.6-rbtree-davem-fixed/include/net/tcp.h 2007-09-19
> 17:36:07.0 -0700
> +++ linux-2.6.22.6-rbtree-tomq/include/net/tcp.h 2007-09-19
> 12:22:06.0 -0700
> @@ -1213,6 +1213,11 @@
...Btw, please always use -p to diff as well as it helps review :-).
> sk->sk_send_head = tcp_write_queue_next(sk, skb);
> if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue)
> sk->sk_send_head = NULL;
> + else
> + /* update fack_count of send_head. Since we've sent skb already,
> + * its packet count must be set by now. */
> + TCP_SKB_CB(sk->sk_send_head)->fack_count =
> + TCP_SKB_CB(skb)->fack_count + tcp_skb_pcount(skb);
>
> /* Don't override Nagle indefinately with F-RTO */
> if (tp->frto_counter == 2)
> tp->frto_counter = 3;
> @@ -1310,19 +1315,22 @@
> /* An insert into the middle of the write queue causes the fack
> * counts in subsequent packets to become invalid, fix them up.
> */
> -static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff
> *first)
> +static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff
> *skb)
> {
> - struct sk_buff *prev = first->prev;
> + struct sk_buff *prev = skb->prev;
> unsigned int fc = 0;
>
> if (prev != (struct sk_buff *) &sk->sk_write_queue)
> fc = TCP_SKB_CB(prev)->fack_count + tcp_skb_pcount(prev);
>
> - while (first != (struct sk_buff *)&sk->sk_write_queue) {
> - TCP_SKB_CB(first)->fack_count = fc;
> + while (skb != (struct sk_buff *)&sk->sk_write_queue) {
> + if (TCP_SKB_CB(skb)->fack_count == fc || !tcp_skb_pcount(skb))
What is this !tcp_skb_pcount(skb) for I think what we really want here
is this:|| (skb == tcp_send_head(sk))
> + break;
>
> - fc += tcp_skb_pcount(first);
> - first = first->next;
> + TCP_SKB_CB(skb)->fack_count = fc;
> +
> + fc += tcp_skb_pcount(skb);
> + skb = skb->next;
> }
> }
>
> diff -ur linux-2.6.22.6-rbtree-davem-fixed/net/ipv4/tcp_input.c
> linux-2.6.22.6-rbtree-tomq/net/ipv4/tcp_input.c
> --- linux-2.6.22.6-rbtree-davem-fixed/net/ipv4/tcp_input.c2007-09-13
> 18:23:16.0 -0700
> +++ linux-2.6.22.6-rbtree-tomq/net/ipv4/tcp_input.c 2007-09-19
> 12:27:42.0 -0700
> @@ -956,6 +956,7 @@
> int fack_count_base;
> int i;
> int first_sack_index;
> + u32 prev_end_seq = 0;
>
> if (!tp->sacked_out)
> tp->fackets_out = 0;
> @@ -1000,6 +1001,7 @@
> if (i == 0) {
> if (tp->recv_sack_cache[i].start_seq != start_seq)
> flag = 0;
> + prev_end_seq = ntohl(tp->recv_sack_cache[i].end_seq);
> } else {
> if ((tp->recv_sack_cache[i].start_seq != start_seq) ||
> (tp->recv_sack_cache[i].end_seq != end_seq))
> @@ -1016,9 +1018,16 @@
>
> first_sack_index = 0;
> if (flag)
> + /* all that has changed is end of first SACK block. So all we
> + * need to do is tag those skbs that were'nt tagged last time.
> */
IMHO, a bit verbose comment. Besides, we already tell above that what SACK
fastpath is all about...
> num_sacks = 1;
> else {
> int j;
> +
> + /* more than just end of first SACK block has changed;
> invalidate
> + * prev_end_seq */
> +
> + prev_end_seq = 0;
Don't tell what's obvious from code as well.
> /* order SACK blocks to allow in order walk of the retrans
> queue */
> for (i = num_sacks-1; i > 0; i--) {
> @@ -1051,6 +1060,8 @@
> int fack_count;
> int dup_sack = (found_dup_sack && (i == first_sack_index));
>
> + if (prev_end_seq) start_seq = prev_end_seq;
> +
...We never add statements on the same line after if statements (see
Documentation/CodingStyle)
--
i.
-
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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 09:37 -0400, jamal wrote: > On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote: > > On Fri, 2007-09-21 at 07:59 -0400, jamal wrote: > > > > Which would make it a bug. AFAIK, the minimum VLAN tagged packet going > > > out is 68 bytes. > > Are you sure about this? > > This is what i have always seen. If the first email caused confusion - so will this ;-> I have never used e1000 for vlan tagging. My view is that if it emits (instead of 68B) 64B packets with tags then it is buggy and needs to be fixed. Hope that makes sense. cheers, jamal - 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 1/2] David Miller's rbtree patches for 2.6.22.6
On Wed, 19 Sep 2007, Tom Quetchenbach wrote:
> Patch 1: David Miller's red-black tree code, tweaked for 2.6.22.6,
> with some bugfixes
It would help if you would leave the original changes as is (rb-tree and
fack_count separated) and add your work on top of that...
> diff -ur linux-2.6.22.6/include/net/tcp.h
> linux-2.6.22.6-rbtree-davem-fixed/include/net/tcp.h
> --- linux-2.6.22.6/include/net/tcp.h 2007-08-30 23:21:01.0 -0700
> +++ linux-2.6.22.6-rbtree-davem-fixed/include/net/tcp.h 2007-09-19
> 17:36:07.0 -0700
> @@ -540,6 +540,7 @@
> __u32 seq;/* Starting sequence number */
> __u32 end_seq;/* SEQ + FIN + SYN + datalen*/
> __u32 when; /* used to compute rtt's*/
> + unsigned intfack_count; /* speed up SACK processing */
> __u8flags; /* TCP header flags.*/
>
> /* NOTE: These must match up to the flags byte in a
> @@ -1043,12 +1044,12 @@
> }
>
> /*from STCP */
> -static inline void clear_all_retrans_hints(struct tcp_sock *tp){
> +static inline void clear_all_retrans_hints(struct tcp_sock *tp)
> +{
Unrelated change, please don't do that. Besides, it's already fixed in
net-2.6.24.
> tp->lost_skb_hint = NULL;
> tp->scoreboard_skb_hint = NULL;
> tp->retransmit_skb_hint = NULL;
> tp->forward_skb_hint = NULL;
> - tp->fastpath_skb_hint = NULL;
> }
>
> /* MD5 Signature */
> @@ -1227,9 +1229,61 @@
> sk->sk_send_head = NULL;
> }
>
> +static inline struct sk_buff *tcp_write_queue_find(struct sock *sk, __u32
> seq)
> +{
> + struct rb_node *rb_node = tcp_sk(sk)->write_queue_rb.rb_node;
> + struct sk_buff *skb = NULL;
> +
> + while (rb_node) {
> + struct sk_buff *tmp = rb_entry(rb_node,struct sk_buff,rb);
> + if (TCP_SKB_CB(tmp)->end_seq > seq) {
This is old and buggy version of the rb-tree code. Get the latest rb-tree
patch from tcp-2.6 tree.
> + skb = tmp;
> + if (TCP_SKB_CB(tmp)->seq <= seq)
...fixed in tcp-2.6.
> + break;
> + rb_node = rb_node->rb_left;
> + } else
> + rb_node = rb_node->rb_right;
> +
> + }
> + return skb;
> +}
> +
> +static inline void tcp_rb_insert(struct sk_buff *skb, struct rb_root *root)
> +{
> + struct rb_node **rb_link, *rb_parent;
> + __u32 seq = TCP_SKB_CB(skb)->seq;
> +
> + rb_link = &root->rb_node;
> + rb_parent = NULL;
> + while (*rb_link != NULL) {
> + struct sk_buff *tmp = rb_entry(*rb_link,struct sk_buff,rb);
> + rb_parent = *rb_link;
> + if (TCP_SKB_CB(tmp)->end_seq > seq) {
> + BUG_ON(TCP_SKB_CB(tmp)->seq <= seq);
...these are broken as well.
>
> + rb_link = &rb_parent->rb_left;
> + } else {
> + rb_link = &rb_parent->rb_right;
> + }
> + }
> + rb_link_node(&skb->rb, rb_parent, rb_link);
> + rb_insert_color(&skb->rb, root);
> +}
> +
> +static inline void tcp_rb_unlink(struct sk_buff *skb, struct rb_root *root)
> +{
> + rb_erase(&skb->rb, root);
> +}
> +
> static inline void __tcp_add_write_queue_tail(struct sock *sk, struct
> sk_buff *skb)
> {
> + struct sk_buff *tail = tcp_write_queue_tail(sk);
> + unsigned int fc = 0;
> +
> + if (tail)
> + fc = TCP_SKB_CB(tail)->fack_count + tcp_skb_pcount(tail);
> + TCP_SKB_CB(skb)->fack_count = fc;
> __skb_queue_tail(&sk->sk_write_queue, skb);
> + tcp_rb_insert(skb, &tcp_sk(sk)->write_queue_rb);
> }
>
> static inline void tcp_add_write_queue_tail(struct sock *sk, struct sk_buff
> *skb)
> diff -ur linux-2.6.22.6/net/ipv4/tcp_input.c
> linux-2.6.22.6-rbtree-davem-fixed/net/ipv4/tcp_input.c
> --- linux-2.6.22.6/net/ipv4/tcp_input.c 2007-08-30 23:21:01.0
> -0700
> +++ linux-2.6.22.6-rbtree-davem-fixed/net/ipv4/tcp_input.c2007-09-13
> 18:23:16.0 -0700
> @@ -947,14 +947,13 @@
> unsigned char *ptr = (skb_transport_header(ack_skb) +
> TCP_SKB_CB(ack_skb)->sacked);
> struct tcp_sack_block_wire *sp = (struct tcp_sack_block_wire *)(ptr+2);
> - struct sk_buff *cached_skb;
> int num_sacks = (ptr[1] - TCPOLEN_SACK_BASE)>>3;
> int reord = tp->packets_out;
> int prior_fackets;
> u32 lost_retrans = 0;
> int flag = 0;
> int found_dup_sack = 0;
> - int cached_fack_count;
> + int fack_count_base;
> int i;
> int first_sack_index;
>
> @@ -1020,7 +1019,6 @@
> num_sacks = 1;
> else {
> int j;
> - tp->fastpath_skb_hint = NULL;
>
> /* order SACK blocks to allow in order walk of the retrans
> queue */
> for (i = num_sacks-1; i > 0; i--) {
> @@ -1045,14 +1043,7 @@
> /* c
Re: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote: > On Fri, 2007-09-21 at 07:59 -0400, jamal wrote: > > Which would make it a bug. AFAIK, the minimum VLAN tagged packet going > > out is 68 bytes. > Are you sure about this? This is what i have always seen. Double checked with google and she gave me many a url, example: http://www.cisco.com/warp/public/473/741_4.html I think you can pretty much trust cisco on something as basic as this. Also: http://www.techfest.com/networking/lan/ethernet2.htm > We did some extensive testing capturing VLAN > frames going out of our Intel PRO/1000 MT Dual Port Server Adapter > (82571EB chipset) and we definitely captured VLAN frames shorter then 68 > bytes. Here is text dump of such frame: > http://www.tkrjasek.cz/mie/cmts_tests/between_linux_and_cmts.txt Do you have access to another NIC? a tg3 based one will be good to test for hardware level tagging. > (note that wireshark captures the frames without 4 bytes FCS (frame > check sequence) so the above packet is in fact 66 bytes long). > > What is the right behaviour according to specification? In iee802.3, > minFrameSize is 64bytes. I've never seen any document which'd say that > VLAN frames should be 68 bytes minimum. Refer to above. > Now i'm little confused by your reply, becaouse you write, that VLAN > frames generated by e1000 should be 68 bytes minimum, which contradicts > witch our observations. Miscommunication ;-> I said the packets going out should be 68B otherwise it is a bug. if e1000 is sending 64B out, it is a bug. I think any other NIC that doesnt do hardware based vlan tags would be good to try as well because it uses the software stack to do the tagging. cheers, jamal - 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: wrong arp query with policy routing
Marco Berizzi wrote: > inet 1.1.1.1/32 scope global eth0 ^^ Sorry, my fault. Apologies for all the noise. - 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: [RFC/PATCH 2/3] UDP memory usage accounting: accounting unit and variable
Satoshi OSHIMA <[EMAIL PROTECTED]> writes: > This patch introduces global variable for UDP memory accounting. > The unit is page. The global variable doesn't seem to be very MP scalable, especially if you change it for each packet. This will be a very hot cache line, in the worst case bouncing around a large machine. Possible alternatives: - Per CPU variables - You only change the global on socket creation time (by pre allocating a large amount) or when the system comes under memory pressure. - Batching of the global updates for multiple packets [that's a variant of the previous one, might be still too costly though] Also for such variables it's usually good to cache line pad them on SMP to avoid false sharing with something else. -Andi - 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: [RFC/PATCH 0/3] UDP memory usage accounting
Hi. On Fri, Sep 21, 2007 at 09:18:07PM +0900, Satoshi OSHIMA ([EMAIL PROTECTED]) wrote: > This patch set try to introduce memory usage accounting for > UDP(currently ipv4 only). > > Currently, memory usage of UDP can be observed as the sam of > usage of tx_queue and rx_queue. But I believe that the system > wide accounting is usefull when heavy loaded condition. > > In the next step, I would like to add memory usage quota > for UDP to avoid unlimited memory consumption problem > under DDOS attack. Could you please desribed such attack in more details? Each UDP socket has its queue length which can not be exceeded (roughly), no new sockets are created when remote side sends a packet (like after special steps in TCP), so where is possibility to eat all the mem? > This patch set is for 2.6.23-rc7. I seriously doubt you want to put udp specific hacks and zillions of atomic ops all around the code just to know exact number of bytes eaten for UDP. Please use udp specific code (like udp_sendmsg()) for proper accounting if you need that, but not hacks in generic ip code. -- Evgeniy Polyakov - 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: wrong arp query with policy routing
jamal wrote: > On Fri, 2007-21-09 at 11:08 +0200, Marco Berizzi wrote: > > > thanks for the reply. > > I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0', > > but the 'arp whos-has' behaviour doesn't change. > > Other hints? > > Give a man a fish and he'll eat for a day > > Documentation/networking/ip-sysctl.txt Thanks for the tip Jamal. I have done a 'grep -i arp' on that file and arp_announce should do the trick. But I always get the same behaviour, after: echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce Here is: 14:43:26.096574 00:01:02:ad:db:82 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 1.1.1.254 tell 172.16.1.247 Here is my 'ip a s' output: 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:01:02:ad:db:82 brd ff:ff:ff:ff:ff:ff inet 172.16.1.247/23 brd 172.16.1.255 scope global eth0 inet 1.1.1.1/32 scope global eth0 - 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 3/7] CAN: Add raw protocol
Urs Thuermann wrote: > +config CAN_RAW_USER > + bool "Allow non-root users to access Raw CAN Protocol sockets" If you plan to remove this option, it should happen before merging since it affects userspace visible behaviour. - 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 2/7] CAN: Add PF_CAN core module
Urs Thuermann wrote:
> +static int can_create(struct net *net, struct socket *sock, int protocol)
> +{
> + ...
> +
> + spin_lock(&proto_tab_lock);
> + cp = proto_tab[protocol];
> + if (cp && !try_module_get(cp->prot->owner))
> + cp = NULL;
> + spin_unlock(&proto_tab_lock);
> +
> + /* check for success and correct type */
> + if (!cp || cp->type != sock->type) {
> + ret = -EPROTONOSUPPORT;
> + goto errout;
> + }
> +
> + if (cp->capability >= 0 && !capable(cp->capability)) {
> + ret = -EPERM;
> + goto errout;
> + }
> +
> + sock->ops = cp->ops;
You drop the module reference again when leaving this function.
So sock->ops might contain a stale pointer if the module is
unloaded after this. You need to either keep the module reference
while the socket is alive or remove stale references when
unregistering the protocol.
-
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] PHYLIB: IRQ event workqueue handling fixes
On Thu, 20 Sep 2007, Andrew Morton wrote: > You always put boring, crappy, insufficient text in the for-the-changelog > section and interesting, useful, sufficient text in the not-for-the-changelog > section. I'll swap the sections in the future then. ;-) Frankly I was not sure whether the changelog was happy about being fed with lengthy explanations and it has not spoken out. I have to admit this is a habit carried over from the FSF-style ChangeLog -- where the enforced rule is actually *not* to provide any explanation for why changes are done and only describe what has been modified (with any discussion around archived in the respective mailing list). > But you can't fool me! I have an editor and I fix it up. Thank you and sorry for the extra work I caused you -- I shall keep your suggestion in mind in the future. Maciej - 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-09-21 at 07:59 -0400, jamal wrote: > > Current e1000 (according to our observations) first appends 4 bytes of > > VLAN tag and then pads the frame to 64 bytes with zeroes if necessary > > before transmiting it. > > Which would make it a bug. AFAIK, the minimum VLAN tagged packet going > out is 68 bytes. Are you sure about this? We did some extensive testing capturing VLAN frames going out of our Intel PRO/1000 MT Dual Port Server Adapter (82571EB chipset) and we definitely captured VLAN frames shorter then 68 bytes. Here is text dump of such frame: http://www.tkrjasek.cz/mie/cmts_tests/between_linux_and_cmts.txt (note that wireshark captures the frames without 4 bytes FCS (frame check sequence) so the above packet is in fact 66 bytes long). What is the right behaviour according to specification? In iee802.3, minFrameSize is 64bytes. I've never seen any document which'd say that VLAN frames should be 68 bytes minimum. > > I'd like to change it so it first pads the frame to 64 B and appends the > > VLAN tag afterwards, so the resulting VLAN frame would be 68 bytes > > minimum. > > If you were able to figure this much out: What have you tried and what > do you still need help on? CCing some of the e1000 people(done) will > probably help you get this resolved faster. Well to make long story short. While testing VLAN capabilities of our C3 CMTS, we discovered that some frames are corupted after passing trough the CMTS. We discovered, that affected frames are VLAN frames 64 - 67 bytes long. We tried several NIC's in our linux box mainly with e1000 driver but also some NIC's from 3com, broadcom and Planet. All of them suffer from this issue except NIC from Planet (RTL-8169 chipset), which pads VLAN frames to 68 bytes. The other cards pad VLAN frames only to 64 bytes. We also tried to tag the traffic on some VLAN enabled switches (d-link, edge-core, cisco catalyst) and they also pad VLAN frames to 68 bytes. Now i'm little confused by your reply, becaouse you write, that VLAN frames generated by e1000 should be 68 bytes minimum, which contradicts witch our observations. thanks for your reply Emil - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
lepton wrote: > Yes, you are right. > What do you think about this: > For all packets can be sent out, we just disable > all things in sk_route_caps in ip_route_me_harder Whats the point of doing that? Is rerouting breaking anything for you? - 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
[RFC/PATCH 1/3] UDP memory usage accounting: fix send buffer check
This patch introduces sndbuf size check before
memory allcation for send buffer.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===
--- 2.6.23-rc7-udp_limit.orig/net/ipv4/ip_output.c
+++ 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
@@ -1004,6 +1004,11 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
}
} else if (i < MAX_SKB_FRAGS) {
+ if (atomic_read(&sk->sk_wmem_alloc) + PAGE_SIZE
+ > 2 * sk->sk_sndbuf) {
+ err = -ENOBUFS;
+ goto error;
+ }
if (copy > PAGE_SIZE)
copy = PAGE_SIZE;
page = alloc_pages(sk->sk_allocation, 0);
-
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
[RFC/PATCH 3/3] UDP memory usage accounting: measurement
This patch introduces memory usage measurement for UDP.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===
--- 2.6.23-rc7-udp_limit.orig/net/ipv4/ip_output.c
+++ 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
@@ -743,6 +743,8 @@ static inline int ip_ufo_append_data(str
/* specify the length of each IP datagram fragment*/
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
__skb_queue_tail(&sk->sk_write_queue, skb);
return 0;
@@ -924,6 +926,9 @@ alloc_new_skb:
}
if (skb == NULL)
goto error;
+ if (sk->sk_protocol == IPPROTO_UDP)
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
/*
* Fill in the control structures
@@ -1023,6 +1028,8 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
skb->truesize += PAGE_SIZE;
atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc);
+ if (sk->sk_protocol == IPPROTO_UDP)
+
atomic_inc(sk->sk_prot->memory_allocated);
} else {
err = -EMSGSIZE;
goto error;
@@ -1123,7 +1130,9 @@ ssize_t ip_append_page(struct sock *sk,
if (unlikely(!skb)) {
err = -ENOBUFS;
goto error;
- }
+ } else if (sk->sk_protocol == IPPROTO_UDP)
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
/*
* Fill in the control structures
@@ -1152,6 +1161,8 @@ ssize_t ip_append_page(struct sock *sk,
/*
* Put the packet on the pending queue.
*/
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
__skb_queue_tail(&sk->sk_write_queue, skb);
continue;
}
@@ -1202,13 +1213,14 @@ int ip_push_pending_frames(struct sock *
struct iphdr *iph;
__be16 df = 0;
__u8 ttl;
- int err = 0;
+ int err = 0, send_page_size;
if ((skb = __skb_dequeue(&sk->sk_write_queue)) == NULL)
goto out;
tail_skb = &(skb_shinfo(skb)->frag_list);
/* move skb->data to ip header from ext header */
+ send_page_size = sk_datagram_pages(skb->truesize);
if (skb->data < skb_network_header(skb))
__skb_pull(skb, skb_network_offset(skb));
while ((tmp_skb = __skb_dequeue(&sk->sk_write_queue)) != NULL) {
@@ -1218,6 +1230,7 @@ int ip_push_pending_frames(struct sock *
skb->len += tmp_skb->len;
skb->data_len += tmp_skb->len;
skb->truesize += tmp_skb->truesize;
+ send_page_size += sk_datagram_pages(tmp_skb->truesize);
__sock_put(tmp_skb->sk);
tmp_skb->destructor = NULL;
tmp_skb->sk = NULL;
@@ -1269,6 +1282,8 @@ int ip_push_pending_frames(struct sock *
/* Netfilter gets whole the not fragmented skb. */
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
skb->dst->dev, dst_output);
+ if (sk->sk_protocol == IPPROTO_UDP)
+ atomic_sub(send_page_size, sk->sk_prot->memory_allocated);
if (err) {
if (err > 0)
err = inet->recverr ? net_xmit_errno(err) : 0;
@@ -1299,8 +1314,12 @@ void ip_flush_pending_frames(struct sock
struct inet_sock *inet = inet_sk(sk);
struct sk_buff *skb;
- while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL)
+ while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) {
+ if (sk->sk_protocol == IPPROTO_UDP)
+ atomic_sub(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
kfree_skb(skb);
+ }
inet->cork.flags &= ~IPCORK_OPT;
kfree(inet->cork.opt);
Index: 2.6.23-rc7-udp_limit/net/ipv4/udp.c
===
--- 2.6.23-rc7-udp_limi
[RFC/PATCH 2/3] UDP memory usage accounting: accounting unit and variable
This patch introduces global variable for UDP memory accounting.
The unit is page.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc3-udp_limit/include/net/sock.h
===
--- 2.6.23-rc3-udp_limit.orig/include/net/sock.h
+++ 2.6.23-rc3-udp_limit/include/net/sock.h
@@ -723,6 +723,13 @@ static inline int sk_stream_wmem_schedul
sk_stream_mem_schedule(sk, size, 0);
}
+#define SK_DATAGRAM_MEM_QUANTUM ((int)PAGE_SIZE)
+
+static inline int sk_datagram_pages(int amt)
+{
+ return DIV_ROUND_UP(amt, SK_DATAGRAM_MEM_QUANTUM);
+}
+
/* Used by processes to "lock" a socket state, so that
* interrupts and bottom half handlers won't change it
* from under us. It essentially blocks any incoming
Index: 2.6.23-rc3-udp_limit/include/net/udp.h
===
--- 2.6.23-rc3-udp_limit.orig/include/net/udp.h
+++ 2.6.23-rc3-udp_limit/include/net/udp.h
@@ -65,6 +65,8 @@ extern rwlock_t udp_hash_lock;
extern struct proto udp_prot;
+extern atomic_t udp_memory_allocated;
+
struct sk_buff;
/*
Index: 2.6.23-rc3-udp_limit/net/ipv4/proc.c
===
--- 2.6.23-rc3-udp_limit.orig/net/ipv4/proc.c
+++ 2.6.23-rc3-udp_limit/net/ipv4/proc.c
@@ -66,7 +66,8 @@ static int sockstat_seq_show(struct seq_
fold_prot_inuse(&tcp_prot), atomic_read(&tcp_orphan_count),
tcp_death_row.tw_count, atomic_read(&tcp_sockets_allocated),
atomic_read(&tcp_memory_allocated));
- seq_printf(seq, "UDP: inuse %d\n", fold_prot_inuse(&udp_prot));
+ seq_printf(seq, "UDP: inuse %d mem %d\n", fold_prot_inuse(&udp_prot),
+ atomic_read(&udp_memory_allocated));
seq_printf(seq, "UDPLITE: inuse %d\n", fold_prot_inuse(&udplite_prot));
seq_printf(seq, "RAW: inuse %d\n", fold_prot_inuse(&raw_prot));
seq_printf(seq, "FRAG: inuse %d memory %d\n", ip_frag_nqueues,
Index: 2.6.23-rc3-udp_limit/net/ipv4/udp.c
===
--- 2.6.23-rc3-udp_limit.orig/net/ipv4/udp.c
+++ 2.6.23-rc3-udp_limit/net/ipv4/udp.c
@@ -113,6 +113,10 @@ DEFINE_SNMP_STAT(struct udp_mib, udp_sta
struct hlist_head udp_hash[UDP_HTABLE_SIZE];
DEFINE_RWLOCK(udp_hash_lock);
+atomic_t udp_memory_allocated;
+
+EXPORT_SYMBOL(udp_memory_allocated);
+
static int udp_port_rover;
static inline int __udp_lib_lport_inuse(__u16 num, struct hlist_head
udptable[])
-
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
[RFC/PATCH 0/3] UDP memory usage accounting
This patch set try to introduce memory usage accounting for UDP(currently ipv4 only). Currently, memory usage of UDP can be observed as the sam of usage of tx_queue and rx_queue. But I believe that the system wide accounting is usefull when heavy loaded condition. In the next step, I would like to add memory usage quota for UDP to avoid unlimited memory consumption problem under DDOS attack. This patch set is for 2.6.23-rc7. Unfortunately, I don't have any NIC with UFO. So this patch set is not tested with UFO supported device. I appreciate your comment/test/feedback. Satoshi Oshima - 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: wrong arp query with policy routing
On Fri, 2007-21-09 at 11:08 +0200, Marco Berizzi wrote: > thanks for the reply. > I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0', > but the 'arp whos-has' behaviour doesn't change. > Other hints? Give a man a fish and he'll eat for a day Documentation/networking/ip-sysctl.txt cheers, jamal - 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: [LARTC] ifb and ppp
On Fri, 2007-21-09 at 13:56 +0200, Patrick McHardy wrote: > This doesn't help much since he uses the iptables marks for > classification on the ifb device, so he might as well just > classify directly using u32. true. > I think it would be nice to > have an ematch equivalent to the ipt action for matches. yes, that would help in his case. > Should be pretty easy to write > (slightly above 60 seconds > according to the documentation :)). Ah, i hadnt paid attention to that before;-> I'd like to use that whole thing on a tshirt. cheers, jamal - 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: [LARTC] ifb and ppp
jamal wrote: > On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote: > >> I don't see a good solution for this that >>allows to keep the iptables rules, I'd suggest to switch to ematches. > > > One approach could be to use ipt action: > > --- > tc filter add dev ppp0 parent : protocol ip u32 match u32/ematch > some match flowid 1:1 action ipt -j mark --set-mark 1 > .. > ... > > iptables here to use the marks ... This doesn't help much since he uses the iptables marks for classification on the ifb device, so he might as well just classify directly using u32. I think it would be nice to have an ematch equivalent to the ipt action for matches. Should be pretty easy to write (slightly above 60 seconds according to the documentation :)). - 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: change the way e1000 is handling short VLAN frames
On Fri, 2007-21-09 at 09:31 +0200, Emil Micek wrote: > Hello list, > > I'd like to change behaviour of e1000 module when transmiting short > ethernet frames (shorter then 64 bytes) trough VLAN interface. > > Current e1000 (according to our observations) first appends 4 bytes of > VLAN tag and then pads the frame to 64 bytes with zeroes if necessary > before transmiting it. Which would make it a bug. AFAIK, the minimum VLAN tagged packet going out is 68 bytes. > I'd like to change it so it first pads the frame to 64 B and appends the > VLAN tag afterwards, so the resulting VLAN frame would be 68 bytes > minimum. If you were able to figure this much out: What have you tried and what do you still need help on? CCing some of the e1000 people(done) will probably help you get this resolved faster. cheers, jamal - 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] sb1250-mac: Driver model & phylib update
A driver model and phylib update. It includes the following changes: 1. Removal of unused module options. 2. Phylib support and the resulting removal of generic bits for handling the PHY. 3. Proper reserving of device resources and using ioremap()ped handles to access MAC registers rather than platform-specific macros. 4. Handling of the device using the driver model. Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]> --- This is a resubmission and this patch has waited for some time now as the original submission triggered some concerns on the way phylib handled interrupt-driven PHY units. The issues were resolved a while ago already, but I was distracted by some other work, mainly in the toolchain area, so this got postponed this far. For some background information -- as a reminder -- here is the original long explanation I gave back then: "Here is a set of patches that update the sb1250-mac driver used for the onchip Gigabit Ethernet interfaces of the Broadcom SiByte family of SOCs including the BCM1250 and a couple of other members. These are used, among others, on various Broadcom evaluation boards together with Broadcom Gigabit Ethernet PHY chips. Changes include porting the driver to the driver model as a platform device, support for phylib, including the BCM54xx PHYs in the interrupt mode, proper resource managment and a couple of minor clean-ups. Apart from changes to networking code, there are a few required in the architecture-specific areas and therefore I am sending these changes to Ralf and the linux-mips list as well. It might also involve a few more interested parties in the discussion. The changes were tested with a Broadcom SWARM board, which includes a BCM1250 part which has 3 MAC units on chip, of which 2 are usable, with BCM5421 PHY chips attached (both wired to the same interrupt line, which made testing whether IRQ sharing works properly in phylib possible). Link partners included a 1000base and a 100base interface doing autonegotiation as well as a 10base one doing none. Other Broadcom boards that I know of may have these or BCM5411 or BCM5461 chips. The lack of documentation or at least actual pieces of hardware makes the use of interrupts impossible for all but the SWARM, the Sentosa and the Shorty (with the latter unsupported by Linux)." All the bits except from the mentioned architecture-specific fix -- the firmware of the SWARM gets the polarity of the PHY IRQ line wrong, which has to be reprogrammed in the SOC -- have found their way into Linux already. The polarity fix is not critical for the update provided here as the update has been written such that with the current state of affairs the driver will use the polled mode of phylib operation. I will provide the architecture-specific fix later on, probably once this update has propagated back to the linux-mips.org tree (suggestions as to why I should do otherwise certainly welcome). This way if any problems are seen due to the switch of the PHY to the interrupt-driven mode, they can be sorted out independently of this change. This change applies to the current netdev-2.6.git#upstream tree, on top of "patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9" submitted yesterday. Please apply. Maciej patch-netdev-2.6.23-rc6-20070920-sb1250-mac-29 diff -up --recursive --new-file linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/Kconfig linux-netdev-2.6.23-rc6-20070920/drivers/net/Kconfig --- linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/Kconfig 2007-09-20 17:55:14.0 + +++ linux-netdev-2.6.23-rc6-20070920/drivers/net/Kconfig2007-09-20 20:31:42.0 + @@ -2126,6 +2126,7 @@ config R8169_VLAN config SB1250_MAC tristate "SB1250 Gigabit Ethernet support" depends on SIBYTE_SB1xxx_SOC + select PHYLIB ---help--- This driver supports Gigabit Ethernet interfaces based on the Broadcom SiByte family of System-On-a-Chip parts. They include diff -up --recursive --new-file linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c --- linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c 2007-09-20 18:09:18.0 + +++ linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c 2007-09-20 21:06:55.0 + @@ -1,5 +1,6 @@ /* * Copyright (C) 2001,2002,2003,2004 Broadcom Corporation + * Copyright (c) 2006, 2007 Maciej W. Rozycki * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -18,7 +19,12 @@ * * This driver is designed for the Broadcom SiByte SOC built-in * Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp. + * + * Updated to the driver model and the PHY abstraction layer + * by Maciej W. Rozycki. */ + +#include #include #include #include @@ -32,9 +38,15 @@ #include #inclu
Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently run softirq network code on SMP
On Fri, 2007-21-09 at 07:43 -0400, jamal wrote: > one cpu in either bottom/top half has to be slightly loaded and you > loose the ordering where incoming doesnt match outgoing packet order. Actually in your case it gets worse because (if i read that code correctly) you randomly select the CPUs. cheers, jamal - 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: 2.6.13-15-SMP 3/3] network: concurrently run softirq network code on SMP
On Fri, 2007-21-09 at 17:25 +0800, John Ye wrote: > David, > > Thanks for your reply. I understand it's not worth to do. > > I have made it a loadable module to fulfill the function. it mainly for busy > NAT gateway server with SMP to speed up. > John, It was a little hard to read your code; however, it does seems to me like will cause a massive amount of packet reordering to the end hosts using you as the gateway especially when it is receiving a lot of packets/second. You have a queue per CPU that connects your bottom and top half and several CPUs that may service a single NIC in your bottom half. one cpu in either bottom/top half has to be slightly loaded and you loose the ordering where incoming doesnt match outgoing packet order. cheers, jamal - 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: [LARTC] ifb and ppp
On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote: > I don't see a good solution for this that > allows to keep the iptables rules, I'd suggest to switch to ematches. One approach could be to use ipt action: --- tc filter add dev ppp0 parent : protocol ip u32 match u32/ematch some match flowid 1:1 action ipt -j mark --set-mark 1 .. ... iptables here to use the marks ... cheers, jamal - 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 2/2] bnx2: move gzip unpacker to zlib
On Friday 21 September 2007 12:01, Denys Vlasenko wrote: > I will move this code > out of the driver and into zlib in follow-on patch. No, I won't. I accidentally attached both patches to first email, you can find it there. Sorry. -- vda - 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 1/2] bnx2: factor out gzip unpacker
Hi Jeff,
This patch modifies gzip unpacking code in bnx2 driver so that
it does not depend on bnx2 internals. I will move this code
out of the driver and into zlib in follow-on patch.
It can be useful in other drivers which need to store firmwares
or any other relatively big binary blobs - fonts, cursor bitmaps,
whatever.
Patch is run tested by Michael Chan (driver author).
Michael, can you add your ACK?
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN linux-2.6.23-rc6/drivers/net/bnx2.c linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c
--- linux-2.6.23-rc6/drivers/net/bnx2.c 2007-09-14 00:08:11.0 +0100
+++ linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c 2007-09-21 11:44:03.0 +0100
@@ -52,6 +52,8 @@
#include "bnx2_fw.h"
#include "bnx2_fw2.h"
+#define FW_BUF_SIZE 0x8000
+
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
#define DRV_MODULE_VERSION "1.6.4"
@@ -2767,89 +2769,45 @@ bnx2_set_rx_mode(struct net_device *dev)
spin_unlock_bh(&bp->phy_lock);
}
-#define FW_BUF_SIZE 0x8000
-
+/* To be moved to generic lib/ */
static int
-bnx2_gunzip_init(struct bnx2 *bp)
+bnx2_gunzip(void *gunzip_buf, unsigned sz, u8 *zbuf, int len)
{
- if ((bp->gunzip_buf = vmalloc(FW_BUF_SIZE)) == NULL)
- goto gunzip_nomem1;
+ struct z_stream_s *strm;
+ int rc;
- if ((bp->strm = kmalloc(sizeof(*bp->strm), GFP_KERNEL)) == NULL)
- goto gunzip_nomem2;
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+ * is stripped */
- bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
- if (bp->strm->workspace == NULL)
+ rc = -ENOMEM;
+ strm = kmalloc(sizeof(*strm), GFP_KERNEL);
+ if (strm == NULL)
+ goto gunzip_nomem2;
+ strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ if (strm->workspace == NULL)
goto gunzip_nomem3;
- return 0;
+ strm->next_in = zbuf;
+ strm->avail_in = len;
+ strm->next_out = gunzip_buf;
+ strm->avail_out = sz;
+
+ rc = zlib_inflateInit2(strm, -MAX_WBITS);
+ if (rc == Z_OK) {
+ rc = zlib_inflate(strm, Z_FINISH);
+ /* after Z_FINISH, only Z_STREAM_END is "we unpacked it all" */
+ if (rc == Z_STREAM_END)
+ rc = sz - strm->avail_out;
+ else
+ rc = -EINVAL;
+ zlib_inflateEnd(strm);
+ } else
+ rc = -EINVAL;
+ kfree(strm->workspace);
gunzip_nomem3:
- kfree(bp->strm);
- bp->strm = NULL;
-
+ kfree(strm);
gunzip_nomem2:
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
-
-gunzip_nomem1:
- printk(KERN_ERR PFX "%s: Cannot allocate firmware buffer for "
- "uncompression.\n", bp->dev->name);
- return -ENOMEM;
-}
-
-static void
-bnx2_gunzip_end(struct bnx2 *bp)
-{
- kfree(bp->strm->workspace);
-
- kfree(bp->strm);
- bp->strm = NULL;
-
- if (bp->gunzip_buf) {
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
- }
-}
-
-static int
-bnx2_gunzip(struct bnx2 *bp, u8 *zbuf, int len, void **outbuf, int *outlen)
-{
- int n, rc;
-
- /* check gzip header */
- if ((zbuf[0] != 0x1f) || (zbuf[1] != 0x8b) || (zbuf[2] != Z_DEFLATED))
- return -EINVAL;
-
- n = 10;
-
-#define FNAME 0x8
- if (zbuf[3] & FNAME)
- while ((zbuf[n++] != 0) && (n < len));
-
- bp->strm->next_in = zbuf + n;
- bp->strm->avail_in = len - n;
- bp->strm->next_out = bp->gunzip_buf;
- bp->strm->avail_out = FW_BUF_SIZE;
-
- rc = zlib_inflateInit2(bp->strm, -MAX_WBITS);
- if (rc != Z_OK)
- return rc;
-
- rc = zlib_inflate(bp->strm, Z_FINISH);
-
- *outlen = FW_BUF_SIZE - bp->strm->avail_out;
- *outbuf = bp->gunzip_buf;
-
- if ((rc != Z_OK) && (rc != Z_STREAM_END))
- printk(KERN_ERR PFX "%s: Firmware decompression error: %s\n",
- bp->dev->name, bp->strm->msg);
-
- zlib_inflateEnd(bp->strm);
-
- if (rc == Z_STREAM_END)
- return 0;
-
return rc;
}
@@ -2902,22 +2860,21 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_
/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
if (fw->gz_text) {
- u32 text_len;
- void *text;
-
- rc = bnx2_gunzip(bp, fw->gz_text, fw->gz_text_len, &text,
- &text_len);
- if (rc)
- return rc;
-
- fw->text = text;
- }
- if (fw->gz_text) {
+ u32 *text;
int j;
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, fw->gz_text, fw->gz_text_len);
+ if (rc < 0) {
+ vfree(text);
+ return rc;
+ }
for (j = 0; j < (fw->text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(fw->text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
}
+ vfree(text);
}
/* Load the Data area. */
@@ -2979,27 +2936,27 @@ bnx2_init_cpus(struct bnx2 *bp)
{
struct cpu_reg cpu_reg;
struct fw_info *fw;
- int rc = 0;
+ int rc;
void *text;
- u32 text_len;
-
- if ((rc = bnx2_gunzip_init(bp)) != 0)
- return rc;
/* Initialize the RV2P processor. */
- rc = bnx2_gunzip(bp, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1), &text,
- &text_len);
- if (rc)
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, bnx2_rv2p_proc1, sizeof(bnx2_rv2p
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Joe Perches <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-20 at 20:43 +0200, Urs Thuermann wrote:
> > +#define DBG(...) (debug & 1 ? \
> > + (printk(KERN_DEBUG "can-%s %s: ", \
> > + IDENT, __func__), printk(args)) : 0)
> > +#define DBG_FRAME(args...) (debug & 2 ? can_debug_cframe(args) : 0)
> > +#define DBG_SKB(skb) (debug & 4 ? can_debug_skb(skb) : 0)
> > +#else
> > +#define DBG(args...)
> > +#define DBG_FRAME(args...)
> > +#define DBG_SKB(skb)
> > +#endif
>
> Shouldn't these be like the more common
>
> #define DBG(fmt, args...) \
When I wrote these macros we had one platform where we still used
linux-2.4 and gcc-2.95.3 and with that old gcc your macro def would
mean you can't use DBG with only one argument, like DBG("some string\n");
since gcc-2.95 would leave the , after __func__ followed by the
closing ")". I didn't find a way with gcc-2.95 to make the format
string a separate macro argument (which I also wanted). OK, that's
history now and linux-2.6 needs gcc-3/4 anyway, so I will change this.
> do { \
> if (debug & 1) \
> printk(KERN_DEBUG "can-%s %s: " fmt, IDENT, __func__, ##args); \
> } while (0)
I use "do { ... } while(0)" only for statements, not for expressions.
But I could have used the && instead of ?: operator. I don't think
the "do { ... } while(0)" looks nicer or has any other advantage.
> > void can_debug_cframe(const char *msg, struct can_frame *cf, ...)
>
> This prototype looks backwards to me.
You mean the order or `msg' and `cf'? You want to switch them so that
the variable args follow immediately the format string? Might make
sense, OTOH we wanted to have the message as the first argument.
> I'd prefer something like this, which removes the unnecessary
> kmalloc/kfree pairs or the equivalent conversions to functions.
>
> #define can_debug_cframe(cf, fmt, arg...) \
> do { \
> char buf[20]; \
> int dlc = cf->can_dlc; \
> if (dlc > 8) \
> dlc = 8; \
> if (cf->can_id & CAN_EFF_FLAG) \
> sprintf(buf, "<%08X> [%X] ", cf->can_id & CAN_EFF_MASK, dlc); \
> else \
> sprintf(buf, "<%03X> [%X] ", cf->can_id & CAN_SFF_MASK, dlc); \
> printk(KERN_DEBUG fmt, ##arg); \
> print_hex_dump(buf, DUMP_PREFIX_NONE, cf->data, dlc); \
> } while (0)
Ah, I didn't know print_hex_dump(). That looks nicer. But as Thomas
mentioned, we shouldn't convert these functions into macros.
urs
-
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: 2.6.13-15-SMP 3/3] network: concurrently run softirq network code on SMP
David, Thanks for your reply. I understand it's not worth to do. I have made it a loadable module to fulfill the function. it mainly for busy NAT gateway server with SMP to speed up. John Ye - Original Message - From: "David Miller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, September 21, 2007 1:46 AM Subject: Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently run softirq network code on SMP > > The whole reason the queues are per-cpu is so that we do not > have to touch remote processor state nor use locks of any > kind whatsoever. > > With multi-queue networking cards becoming more and more > available, which will split up the packet workload in > hardware across all available cpus, there is less and less > reason to make a patch like this one. > > We've known about this issue for ages, and if we felt it > was appropriate to make this change, we would have done > so years ago. > - 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: wrong arp query with policy routing
Chuck Ebbert wrote: > > Is there a way to force linux to make an arp > > probe with the source ip belonging to the > > same subnet requesting ip? > > Umm, arp_filter? Hello Chuck, thanks for the reply. I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0', but the 'arp whos-has' behaviour doesn't change. Other hints? - 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
change the way e1000 is handling short VLAN frames
Hello list, I'd like to change behaviour of e1000 module when transmiting short ethernet frames (shorter then 64 bytes) trough VLAN interface. Current e1000 (according to our observations) first appends 4 bytes of VLAN tag and then pads the frame to 64 bytes with zeroes if necessary before transmiting it. I'd like to change it so it first pads the frame to 64 B and appends the VLAN tag afterwards, so the resulting VLAN frame would be 68 bytes minimum. I want to do it because C3 CMTS from arris, which is connected to our linux box, has problems handling VLAN frames shorter then 68 bytes. As i'm quite a newbie concerning linux sources and c programing, i'd like to ask you if this'd be trivial or complex change and if someone can point out relevant portions of the sources, where the necessary changes should be done. Regards Emil Micek - 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: Please pull 'iwlwifi' branch of wireless-2.6
On Fri, Sep 21, 2007 at 09:20:30AM +0800, Zhu Yi wrote: > > The depends on m for CONFIG_IWL4965 and CONFIG_IWL3945 needs to go, > > we don't put drivers int that need to be modular. > > Since we splited the code base for 3945 and 4965 by a simple "fork" of > file iwl-base.c, some non-static functions names remain the same. Make > the two drivers build into vmlinux at the same time will cause conflict. > So to make them depend on m is a current workaround for .24. We will > abstract a common iwl-core.ko and make driver specific iwl3945.ko and > iwl4965.ko depend on it in .25 time frame. This kind of stuff is not what we want to leak into mainline. If you're too busy to do that 5 minute sed search and replace I'll do it for you. - 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: Pull request for 'r8169-for-jeff-20070919' branch
Chuck Ebbert <[EMAIL PROTECTED]> : [...] > Looking again, it may not be r8169's fault, but it is involved. It Sort of: [...] * Hung when moving data off a physical disk in an LVM. Twice during night. * Hung when adding a disk to a software Raid. Once. > used to hang and could be restarted by pulling the cable and reinserting > it, This is already worked around in 2.6.22-stable. > but now it just locks solid: > > https://bugzilla.redhat.com/show_bug.cgi?id=252955 A part of it look like the usual samba + 816x failure. The most recent changeset in the patch submitted for inclusion should be applied. -- 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
