* [PATCH 0/3 #2] avoid pci_find_device
From: Jiri Slaby @ 2006-05-26 0:07 UTC (permalink / raw)
To: Greg KH
Cc: Linux Kernel Mailing List, linux-pci, jgarzik, netdev, khali,
lm-sensors, stevel, source, mb, st3, linville
Hello,
there are some patches to avoid pci_find_device in drivers, next will come in
future.
Take #2.
It's against 2.6.17-rc4-mm3 tree.
01-i2c-scx200-acb-avoid-pci-find-device.patch
02-bcm43xx-avoid-pci-find-device.patch
03-gt96100eth-avoid-pci-find-device.patch
i2c/busses/scx200_acb.c | 9 ++++++---
net/gt96100eth.c | 10 +++++++---
net/wireless/bcm43xx/bcm43xx_main.c | 20 ++++++++++++++++----
3 files changed, 29 insertions(+), 10 deletions(-)
Thanks.
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: James Morris @ 2006-05-26 0:06 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <44760E29.4070407@hp.com>
On Thu, 25 May 2006, Paul Moore wrote:
> This patch introduces a new kernel feature designed to support labeled
> networking protocols such as RIPSO and CIPSO. These protocols are required to
> interoperate with existing "trusted" operating systems such as Trusted
> Solaris.
A few initial comments.
- Did you decide that you definitely need to verify labels on fragments?
I can see the code's been added to do that, but wonder about a comment
made during earlier discussion that mislabeled fragments could only come
from a misbehaving trusted system. What is the threat model here?
- Can you explain how module loading and module refcounting for these
modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
always safe to unload if the refcount is zero?)
- What about user APIs for setting and retrieving labels?
- What about labeling of kernel-generated packets?
- Don't put #ifdef'd code into mainline code.
e.g. in net/ipv4/ip_fragment.c
+#ifdef CONFIG_NETLABEL_CIPSOV4
+ if (sopt->cipso) {
This needs to be a function which is compiled away as a static inline when
not selected. This stuff should have zero impact on the networking code
if not enabled.
- Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
protocol.
- This does not follow normal kernel coding practices:
+ if (netlbl_netlink_init() != 0) {
+ netlbl_domhsh_exit();
+ return -ENOMEM;
This should be:
{
err = netlbl_netlink_init();
if (err)
goto err_domhsh;
...
err_domhsh:
netlbl_domhsh_exit();
return err;
}
i.e. a single error path when you have cleanups to perform, and
propagation of error codes.
- This kind of stuff should be removed before merging:
+static void __exit netlbl_exit(void)
+{
+ printk(KERN_INFO "NetLabel: Exiting\n");
+int netlbl_netlink_init(void)
+{
+ BUG_ON(netlbl_nl);
+int netlbl_netlink_exit(void)
+{
+ BUG_ON(!netlbl_nl);
Should the above two be marked __init and __exit? And why does the last
one return an int when the only possible return value is zero? (it needs
to return void).
- Why does this module have a version number?
+ printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n",
+ NETLBL_VER_STR, NETLBL_VER_DATE);
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-25 23:24 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: Pekka Savola, netdev
In-Reply-To: <Pine.LNX.4.64.0605151904110.12081@netcore.fi>
(To YOSHIFUJI Hideaki: this is about the
http://comments.gmane.org/gmane.linux.network/35262 thread)
Tracked it down to IPV6 merge at 2006-03-21:
commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before
the bunch of patches)
commit b00055aacdb172c05067612278ba27265fcd05ce is bad (right after the
bunch of changes)
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h=705af309505681f197f81618440954d10f120dc0;pg=44
shows the list of committs at that range.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* [PATCH 2.6.17-rc5] pcnet32: remove incorrect pcnet32_free_ring
From: Don Fry @ 2006-05-25 23:22 UTC (permalink / raw)
To: tsbogend, jgarzik, netdev
During a code scan for another change I discovered that this call to
pcnet32_free_ring must be removed. If the open fails due to a lack of
memory all the ring structures are removed via the call to free_ring
and a subsequent call to open will dereference a null pointer in
pcnet32_init_ring.
Please apply to 2.6.17.
Signed-off-by: Don Fry <brazilnut@us.ibm.com>
--- linux-2.6.17-rc5/drivers/net/orig.pcnet32.c 2006-05-25 15:59:12.000000000 -0700
+++ linux-2.6.17-rc5/drivers/net/pcnet32.c 2006-05-25 16:09:40.000000000 -0700
@@ -1774,8 +1774,6 @@ static int pcnet32_open(struct net_devic
lp->rx_dma_addr[i] = 0;
}
- pcnet32_free_ring(dev);
-
/*
* Switch back to 16bit mode to avoid problems with dumb
* DOS packet driver after a warm reboot
--
Don Fry
brazilnut@us.ibm.com
^ permalink raw reply
* Re: [PATCH 4/4] [IrDA] ali-ircc: using device model power management
From: David Miller @ 2006-05-25 23:21 UTC (permalink / raw)
To: samuel; +Cc: netdev, irda-users
In-Reply-To: <20060525062052.GD24611@sortiz.org>
From: Samuel Ortiz <samuel@sortiz.org>
Date: Thu, 25 May 2006 06:20:52 +0000
> This patch gets rid of the old power management code and now uses the
> device model for the ali-ircc driver.
>
> Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Enhancement, thus applied to net-2.6.18
Thanks.
^ permalink raw reply
* Re: [PATCH 3/4] [IrDA] stir4200, switching to the kthread API
From: David Miller @ 2006-05-25 23:20 UTC (permalink / raw)
To: samuel; +Cc: netdev, irda-users, hch, shemminger
In-Reply-To: <20060525061944.GC24611@sortiz.org>
From: Samuel Ortiz <samuel@sortiz.org>
Date: Thu, 25 May 2006 06:19:44 +0000
> stir4200 uses a kernel thread for its TX/RX operations, and it is now
> converted to the kernel kthread API.
> Tested on an STIR4200 based dongle.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Enhancement, cleanup, and not a bug fix, so applied to net-2.6.18
Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] [IrDA] Initial support for MCS7780 based dongles
From: David Miller @ 2006-05-25 23:19 UTC (permalink / raw)
To: samuel; +Cc: netdev, irda-users, bpugh
In-Reply-To: <20060525061926.GB24611@sortiz.org>
From: Samuel Ortiz <samuel@sortiz.org>
Date: Thu, 25 May 2006 06:19:27 +0000
> The MosChip MCS7780 chipset is an IrDA USB bridge that
> doesn't conform with the IrDA-USB standard and thus needs
> its separate driver.
> Tested on an actual MCS7780 based dongle.
>
> Original implementation by Brian Pugh <bpugh@cs.pdx.edu>
>
> Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
New feature, so applied to net-2.6.18, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] [IrDA] *_DONGLE should depend on IRTTY_SIR
From: David Miller @ 2006-05-25 23:18 UTC (permalink / raw)
To: samuel; +Cc: netdev, irda-users
In-Reply-To: <20060525061851.GA24611@sortiz.org>
From: Samuel Ortiz <samuel@sortiz.org>
Date: Thu, 25 May 2006 06:18:51 +0000
> If a SIR dongle is built in the kernel while IRTTY_SIR is built
> as a module, kernel compilation will fail.
> Thus, the SIR dongle config should depend on the IRTTY_SIR.
>
> Closes kernel bug# 6512
> (http://bugzilla.kernel.org/show_bug.cgi?id=6512)
>
> Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
Bug fix, so applied to net-2.6, thanks.
^ permalink raw reply
* Re: [patch 0/3] bridge patches for 2.6.18
From: David Miller @ 2006-05-25 23:00 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20060524171216.706750000@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Wed, 24 May 2006 10:12:16 -0700
> Some stuff for 2.6.18. The most important is adding netlink
> support for managing interfaces; this allows building STP
> as an application.
Applied to net-2.6.18, thanks Stephen.
^ permalink raw reply
* Re: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
From: David Miller @ 2006-05-25 22:16 UTC (permalink / raw)
To: herbert; +Cc: akpm, bugme-daemon, netdev
In-Reply-To: <E1Fihtm-0003dO-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 24 May 2006 11:10:54 +1000
> David Miller <davem@davemloft.net> wrote:
> > From: Andrew Morton <akpm@osdl.org>
> > Date: Tue, 23 May 2006 16:31:42 -0700
> >
> >> > Summary: dummy interface broadcast destination hardware address
> >> > is not ff:ff:ff:ff:ff:ff
> >
> > Very strange because the dummy device driver calls
> > ether_setup() which does:
>
> It's caused by the NO_ARP flag.
Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
(but not IFF_LOOPBACK)? I'm talking about the code in
net/ipv4/arp.c that causes this behavior.
^ permalink raw reply
* Re: [PATCH 0/5] LLC SOCK_DGRAM enhancements
From: David Miller @ 2006-05-25 22:11 UTC (permalink / raw)
To: shemminger; +Cc: acme, netdev
In-Reply-To: <20060524000414.052569000@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Tue, 23 May 2006 17:04:14 -0700
> I want to use AF_LLC and SOCK_DGRAM for handling Spanning
> Tree Protocol packets in user space. The existing code doesn't work
> and also doesn't support multicast. These basic problems and
> add some cleanups.
All applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] TCP Veno module for kernel 2.6.16.13
From: David Miller @ 2006-05-25 21:59 UTC (permalink / raw)
To: caitlinb; +Cc: shemminger, ZHOU0022, baruch, jmorris, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F150CE2B@NT-SJCA-0751.brcm.ad.broadcom.com>
From: "Caitlin Bestler" <caitlinb@broadcom.com>
Date: Thu, 25 May 2006 14:11:03 -0700
> The *desirability* of using this data is debatable, but it most
> certainly is possible.
Right, I don't think these kinds of schemes scale very well
personally.
I think TCP can certainly infer these attributes using
existing information. With %100 precision, no of course
not, but definitely a good enough approximation for real
use.
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx kill pci_find_device
From: Michael Buesch @ 2006-05-25 21:55 UTC (permalink / raw)
To: Jiri Slaby
Cc: Jeff Garzik, Greg KH, Linux Kernel Mailing List, linux-pci,
Netdev List
In-Reply-To: <4474FE3E.9040303@garzik.org>
On Thursday 25 May 2006 02:45, you wrote:
> Jiri Slaby wrote:
> > bcm43xx kill pci_find_device
> >
> > Change pci_find_device to safer pci_get_device.
> >
> > Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
> >
> > ---
> > commit 75664d3c6fe1d8d00b87e42cc001cb5d90613dae
> > tree ebcec31955a991f1661197c7e8bcdd682e030681
> > parent 431ef31d431939bc9370f952d9510ab9e5b0ad47
> > author Jiri Slaby <ku@bellona.localdomain> Thu, 25 May 2006 02:04:38 +0159
> > committer Jiri Slaby <ku@bellona.localdomain> Thu, 25 May 2006 02:04:38 +0159
> >
> > drivers/net/wireless/bcm43xx/bcm43xx_main.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > index b488f77..f770f59 100644
> > --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> > @@ -2142,9 +2142,10 @@ #ifdef CONFIG_BCM947XX
> > if (bcm->pci_dev->bus->number == 0) {
> > struct pci_dev *d = NULL;
> > /* FIXME: we will probably need more device IDs here... */
> > - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
> > + d = pci_get_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
> > if (d != NULL) {
> > bcm->irq = d->irq;
> > + pci_dev_put(d);
>
> Given the FIXME, if you are going to touch this area, it seems logical
> to add a PCI device match table.
Yes, you may want to discuss that with the openwrt people, as this
code is only openwrt related.
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Paul Moore @ 2006-05-25 21:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <20060525135846.44791440@localhost.localdomain>
Stephen Hemminger wrote:
> On Thu, 25 May 2006 16:06:01 -0400
> Paul Moore <paul.moore@hp.com> wrote:
>>This patch introduces a new kernel feature designed to support labeled
>>networking protocols such as RIPSO and CIPSO. These protocols are required to
>>interoperate with existing "trusted" operating systems such as Trusted Solaris.
>>I am posting the patch now not because I feel it is ready for inclusion into
>>any of the main kernel trees but because it is usable and I would like to
>>solicit comments from the community sooner rather than later.
>
> Maybe this would be easier and better done via existing netfilter infrastructure?
I think this would be rather difficult on the outbound side as protocols like CIPSO and RIPSO add IP options to the packet. I may be wrong but I thought that adding to the size of the packet was a no-no in netfilter? Also, doesn't netfilter get the packet after the checksum has been calculated and the packet has gone through the xfrm infrastructure?
--
paul moore
linux security @ hp
^ permalink raw reply
* e1000: add WoL fix for 2.6.17rc
From: Auke Kok @ 2006-05-25 21:12 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Jesse Brandeburg, Auke Kok, Kok, Auke
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
Jeff,
Please queue the 'e1000: add shutdown handler back for WoL' for 2.6.17rc's.
Since this fix is already committed to jgarzik/netdev-2.6#upstream, you can
cherrypick it into #upstream-fixes:
$ git-cherry-pick c653e6351e371b33b29871e5eedf610ffb3be037
Cheers,
Auke
[-- Attachment #2: e1000_01_add_shutdown_back.patch --]
[-- Type: text/x-patch, Size: 1465 bytes --]
e1000: add shutdown handler back to fix WOL
Someone was waaay too aggressive and removed e1000's reboot notifier
instead of porting it to the new way of the shutdown handler. This change
broke wake on lan. Add the shutdown handler back in using the same method
as e100 uses.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fb8cef6..b224e40 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -221,6 +221,7 @@ static void e1000_restore_vlan(struct e1
static int e1000_suspend(struct pci_dev *pdev, pm_message_t state);
static int e1000_resume(struct pci_dev *pdev);
#endif
+static void e1000_shutdown(struct pci_dev *pdev);
#ifdef CONFIG_NET_POLL_CONTROLLER
/* for netdump / net console */
@@ -236,8 +237,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .shutdown = e1000_shutdown
};
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
@@ -4605,6 +4607,12 @@ e1000_resume(struct pci_dev *pdev)
return 0;
}
#endif
+
+static void e1000_shutdown(struct pci_dev *pdev)
+{
+ e1000_suspend(pdev, PMSG_SUSPEND);
+}
+
#ifdef CONFIG_NET_POLL_CONTROLLER
/*
* Polling 'interrupt' - used by things like netconsole to send skbs
^ permalink raw reply related
* RE: [PATCH] TCP Veno module for kernel 2.6.16.13
From: Caitlin Bestler @ 2006-05-25 21:11 UTC (permalink / raw)
To: Stephen Hemminger, David Miller; +Cc: ZHOU0022, baruch, jmorris, netdev
netdev-owner@vger.kernel.org wrote:
> On Thu, 25 May 2006 13:23:50 -0700 (PDT) David Miller
> <davem@davemloft.net> wrote:
>
>> From: "#ZHOU BIN#" <ZHOU0022@ntu.edu.sg>
>> Date: Thu, 25 May 2006 16:30:48 +0800
>>
>>> Yes, I agree. Actually the main contribution of TCP Veno is not in
>>> this AI phase. No matter the ABC is added or not, TCP Veno can
>>> always improve the performance over wireless networks, according to
>>> our tests.
>>
>> It seems to me that the wireless issue is seperate from congestion
>> control.
>>
>> The key is to identify "true loss" due to overflow of intermediate
>> router queues, vs. "false loss" which is due to temporary radio
>> signal interference.
>
> Is it really possible to tell the two apart.
Loss due to "true congestion" as opposed to loss due to radio signal
interference (true loss, but falsely inferred to be congestion) is
actually very possible, at L2 and only if the hop experiencing problems
is the first or last hop. There are numerous indicators that
the link is experiencing link-related drops (FEC corrections,
signal to noise, etc.).
The *desirability* of using this data is debatable, but it most
certainly is possible.
^ permalink raw reply
* Re: [PATCH] TCP Veno module for kernel 2.6.16.13
From: David Miller @ 2006-05-25 21:08 UTC (permalink / raw)
To: shemminger; +Cc: ZHOU0022, baruch, jmorris, netdev
In-Reply-To: <20060525135011.470dc3dd@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Thu, 25 May 2006 13:50:11 -0700
> The general idea of resetting cwnd to an estimate of capacity seems to
> be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD
> does the same thing, but they don't have a cool name.
Interesting point.
Eventually such an idea would need to be integrated into another
scheme such as CUBIC, instead of being an entirely different
congestion control scheme, if we ever want to have this facility
in a default congestion control algorithm.
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: David Miller @ 2006-05-25 21:07 UTC (permalink / raw)
To: phil; +Cc: bcook, billfink, jeff, netdev
In-Reply-To: <20060525210412.GC29024@ipom.com>
From: Phil Dibowitz <phil@ipom.com>
Date: Thu, 25 May 2006 14:04:12 -0700
> why would specifically not support a _feature_ of the hardware.
Sparc64 chips support a hash table like hw assist feature for TLB
reloading, I didn't use it for 8+ years and went with a virtual page
table approach instead.
I mean, your statement is totally meaningless. Just because the
hardware can do something, doesn't mean we have any reason to use that
functionality.
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Phil Dibowitz @ 2006-05-25 21:04 UTC (permalink / raw)
To: David Miller; +Cc: bcook, billfink, jeff, netdev
In-Reply-To: <20060525.132928.115910730.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
On Thu, May 25, 2006 at 01:29:28PM -0700, David Miller wrote:
> From: Phil Dibowitz <phil@ipom.com>
> Date: Thu, 25 May 2006 12:22:39 -0700
>
> > So at least, for the _current_ implimentations, this should have no
> > performance impacts.
>
> Regardless, I think this is something that userspace _can_
> take care of reasonably and therefore has no buisness in the
> kernel.
>
> We do not duplicate functionality that is already possible
> _unless_ it is incredibly difficult for userland to do so.
> And in this case I do not think it is difficult for userland
> to interpret the counters in the way you want it to.
>
> So, major NACK on this stuff.
Well, if that's how you feel, I'm probably not going to change your mind,
though I'll emphasize I think any solution in userspace is a work around -
*particularly* since most cards have a command specifically for "clear
stats"... why would specifically not support a _feature_ of the hardware.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC 0/4] NetLabel
From: Stephen Hemminger @ 2006-05-25 20:58 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, James Morris,
Stephen Smalley
In-Reply-To: <44760E29.4070407@hp.com>
On Thu, 25 May 2006 16:06:01 -0400
Paul Moore <paul.moore@hp.com> wrote:
> This patch introduces a new kernel feature designed to support labeled
> networking protocols such as RIPSO and CIPSO. These protocols are required to
> interoperate with existing "trusted" operating systems such as Trusted Solaris.
> I am posting the patch now not because I feel it is ready for inclusion into
> any of the main kernel trees but because it is usable and I would like to
> solicit comments from the community sooner rather than later.
>
> I know there has been at least one previous effort to get CIPSO support into
> the kernel and that was rejected. I have tried to take the feedback from that
> patch into consideration with this patch and create a new mechanism which
> treads as lightly as possible on the core networking stack. I have also
> worked to make the new patch LSM agnostic so that this code can be shared
> amongst multiple LSMs; while I am only providing a patch for SELinux at this
> point I do understand that there is at least one other LSM that is interested
> in making use of this new mechanism.
>
> I understand that there will probably need to be a lengthy review period due
> to the size and complexity of this patch. I also understand that my relative
> inexperience with submitting patches to the Linux kernel will not do much to
> help my cause but I appreciate your patience and any comments you may have.
>
> There is a more information as well as a basic userspace tool for configuration
> of the NetLabel subsystem here:
>
> * http://free.linux.hp.com/~pmoore/projects/linux_cipso
>
Maybe this would be easier and better done via existing netfilter infrastructure?
^ permalink raw reply
* Re: [PATCH] TCP Veno module for kernel 2.6.16.13
From: Stephen Hemminger @ 2006-05-25 20:50 UTC (permalink / raw)
To: David Miller; +Cc: ZHOU0022, baruch, jmorris, netdev
In-Reply-To: <20060525.132350.39157903.davem@davemloft.net>
On Thu, 25 May 2006 13:23:50 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "#ZHOU BIN#" <ZHOU0022@ntu.edu.sg>
> Date: Thu, 25 May 2006 16:30:48 +0800
>
> > Yes, I agree. Actually the main contribution of TCP Veno is not in
> > this AI phase. No matter the ABC is added or not, TCP Veno can
> > always improve the performance over wireless networks, according to
> > our tests.
>
> It seems to me that the wireless issue is seperate from congestion
> control.
>
> The key is to identify "true loss" due to overflow of intermediate
> router queues, vs. "false loss" which is due to temporary radio
> signal interference.
Is it really possible to tell the two apart. Also, a lot of times when
an access point is overloaded, performance is killed because of congestion
overload.
> This determination is a job for the loss detection in the generic ACK
> processing code in tcp_input.c, not for a congestion control algorithm.
> The congestion control algorithm uses the "true loss" information to
> make congestion control decisions.
>
> We already have code that tries to make this differentiation, in the
> form of FRTO, and your techniques can likely be placed there as well.
The general idea of resetting cwnd to an estimate of capacity seems to
be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD
does the same thing, but they don't have a cool name.
^ permalink raw reply
* Re: [PATCH] TCP Compound
From: Stephen Hemminger @ 2006-05-25 20:42 UTC (permalink / raw)
To: Angelo P. Castellani; +Cc: netdev, Francesco Vacirca, Andrea Baiocchi
In-Reply-To: <8dd26e70605250420q31d607a9l7a571069b0f73212@mail.gmail.com>
The existing code did a 64 bit divide directly, which won't work on
32 bit platforms. This is what I am testing, it uses math similar to
TCP CUBIC to do a quad root. It seemed more efficient to just do
one operation rather than two square roots.
---------
diff --git a/net/ipv4/tcp_compound.c b/net/ipv4/tcp_compound.c
index 01048e2..74c26a0 100644
--- a/net/ipv4/tcp_compound.c
+++ b/net/ipv4/tcp_compound.c
@@ -52,8 +52,6 @@
#define TCP_COMPOUND_ALPHA 3U
#define TCP_COMPOUND_BETA 1U
-#define TCP_COMPOUND_KAPPA_POW 3
-#define TCP_COMPOUND_KAPPA_NSQRT 2
#define TCP_COMPOUND_GAMMA 30
#define TCP_COMPOUND_ZETA 1
@@ -156,6 +154,58 @@ static void tcp_compound_state(struct so
vegas_disable(sk);
}
+
+/* 64bit divisor, dividend and result. dynamic precision */
+static inline u64 div64_64(u64 dividend, u64 divisor)
+{
+ u32 d = divisor;
+
+ if (divisor > 0xffffffffULL) {
+ unsigned int shift = fls(divisor >> 32);
+
+ d = divisor >> shift;
+ dividend >>= shift;
+ }
+
+ /* avoid 64 bit division if possible */
+ if (dividend >> 32)
+ do_div(dividend, d);
+ else
+ dividend = (u32) dividend / d;
+
+ return dividend;
+}
+
+/* calculate the quartic root of "a" using Newton-Raphson */
+static u32 qroot(u64 a)
+{
+ u32 x, x1;
+
+ /* Initial estimate is based on:
+ * qrt(x) = exp(log(x) / 4)
+ */
+ x = 1u << (fls64(a) >> 2);
+
+ /*
+ * Iteration based on:
+ * 3
+ * x = ( 3 * x + a / x ) / 4
+ * k+1 k k
+ */
+ do {
+ u64 x3 = x;
+
+ x1 = x;
+ x3 *= x;
+ x3 *= x;
+
+ x = (3 * x + (u32) div64_64(a, x3)) / 4;
+ } while (abs(x1 - x) > 1);
+
+ return x;
+}
+
+
/*
* If the connection is idle and we are restarting,
* then we don't want to do any Vegas calculations
@@ -307,29 +357,23 @@ static void tcp_compound_cong_avoid(stru
dwnd = vegas->dwnd;
if (diff < (TCP_COMPOUND_GAMMA << V_PARAM_SHIFT)) {
- u32 i, j, x, x2;
- u64 v;
-
- v = 1;
-
- for (i = 0; i < TCP_COMPOUND_KAPPA_POW; i++)
- v *= old_wnd;
-
- for (i = 0; i < TCP_COMPOUND_KAPPA_NSQRT; i++) {
- x = 1;
- for (j = 0; j < 200; j++) {
- x2 = (x + v / x) / 2;
-
- if (x2 == x || !x2)
- break;
-
- x = x2;
- }
- v = x;
- }
+ u64 win3;
- x = (u32) v >> TCP_COMPOUND_ALPHA;
+ /*
+ * The TCP Compound paper describes the choice
+ * of "k" determines the agressiveness,
+ * ie. slope of the response function.
+ *
+ * For same value as HSTCP would be 0.8
+ * but for computaional reasons, both the
+ * original authors and this implementation
+ * use 0.75.
+ */
+ win3 = old_wnd;
+ win3 *= old_wnd;
+ win3 *= old_wnd;
+ x = qroot(win3) >> TCP_COMPOUND_ALPHA;
if (x > 1)
dwnd = x - 1;
else
^ permalink raw reply related
* Re: reminder, 2.6.18 window...
From: David Miller @ 2006-05-25 20:29 UTC (permalink / raw)
To: phil; +Cc: bcook, billfink, jeff, netdev
In-Reply-To: <20060525192239.GB29024@ipom.com>
From: Phil Dibowitz <phil@ipom.com>
Date: Thu, 25 May 2006 12:22:39 -0700
> So at least, for the _current_ implimentations, this should have no
> performance impacts.
Regardless, I think this is something that userspace _can_
take care of reasonably and therefore has no buisness in the
kernel.
We do not duplicate functionality that is already possible
_unless_ it is incredibly difficult for userland to do so.
And in this case I do not think it is difficult for userland
to interpret the counters in the way you want it to.
So, major NACK on this stuff.
^ permalink raw reply
* Re: [PATCH] TCP Veno module for kernel 2.6.16.13
From: David Miller @ 2006-05-25 20:23 UTC (permalink / raw)
To: ZHOU0022; +Cc: shemminger, baruch, jmorris, netdev
In-Reply-To: <A975FFC51622704CBEAB749E263D1799015540B5@mail01.student.main.ntu.edu.sg>
From: "#ZHOU BIN#" <ZHOU0022@ntu.edu.sg>
Date: Thu, 25 May 2006 16:30:48 +0800
> Yes, I agree. Actually the main contribution of TCP Veno is not in
> this AI phase. No matter the ABC is added or not, TCP Veno can
> always improve the performance over wireless networks, according to
> our tests.
It seems to me that the wireless issue is seperate from congestion
control.
The key is to identify "true loss" due to overflow of intermediate
router queues, vs. "false loss" which is due to temporary radio
signal interference.
This determination is a job for the loss detection in the generic ACK
processing code in tcp_input.c, not for a congestion control algorithm.
The congestion control algorithm uses the "true loss" information to
make congestion control decisions.
We already have code that tries to make this differentiation, in the
form of FRTO, and your techniques can likely be placed there as well.
^ permalink raw reply
* [PATCH 3/3] ixgb: increment version to 1.0.104-k4
From: Kok, Auke @ 2006-05-25 20:26 UTC (permalink / raw)
To: Garzik, Jeff; +Cc: netdev, Brandeburg, Jesse, Kok, Auke, Kok, Auke
In-Reply-To: <20060525202532.25618.58162.stgit@gitlost.site>
Increment the driver version to 1.0.104-k4
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
---
drivers/net/ixgb/ixgb_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 0e23994..0a0c876 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -52,7 +52,7 @@ static char ixgb_driver_string[] = "Inte
#else
#define DRIVERNAPI "-NAPI"
#endif
-#define DRV_VERSION "1.0.104-k2"DRIVERNAPI
+#define DRV_VERSION "1.0.104-k4"DRIVERNAPI
char ixgb_driver_version[] = DRV_VERSION;
static char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";
--
Auke Kok <auke-jan.h.kok@intel.com>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox