* [PATCH 6/6] tg3: Update version and reldate
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Update version to 3.57.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0779544..beeb612 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.56"
-#define DRV_MODULE_RELDATE "Apr 1, 2006"
+#define DRV_MODULE_VERSION "3.57"
+#define DRV_MODULE_RELDATE "Apr 28, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
^ permalink raw reply related
* [PATCH 5/6] tg3: Fix bug in nvram write
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix bug in nvram write function. If the starting nvram address offset
happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
not get set in the existing code. This patch fixes the bug by changing
the "else if" to "if" so that the last dword condition always gets
checked.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 97e27d8..0779544 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9404,7 +9404,7 @@ static int tg3_nvram_write_block_buffere
if ((page_off == 0) || (i == 0))
nvram_cmd |= NVRAM_CMD_FIRST;
- else if (page_off == (tp->nvram_pagesize - 4))
+ if (page_off == (tp->nvram_pagesize - 4))
nvram_cmd |= NVRAM_CMD_LAST;
if (i == (len - 4))
^ permalink raw reply related
* [PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
the full chip reset during MAC address change, the automatic PHY reset
during chip reset will cause a link down and bonding will not work
properly as a result. With this reset_phy parameter, we can do a chip
reset without link down when changing MAC address or MTU.
Signed-off-by: Gary Zambrano <zambrano@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0ccfb63..97e27d8 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3544,7 +3544,7 @@ static irqreturn_t tg3_test_isr(int irq,
return IRQ_RETVAL(0);
}
-static int tg3_init_hw(struct tg3 *);
+static int tg3_init_hw(struct tg3 *, int);
static int tg3_halt(struct tg3 *, int, int);
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -3580,7 +3580,7 @@ static void tg3_reset_task(void *_data)
tp->tg3_flags2 &= ~TG3_FLG2_RESTART_TIMER;
tg3_halt(tp, RESET_KIND_SHUTDOWN, 0);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
@@ -4055,7 +4055,7 @@ static int tg3_change_mtu(struct net_dev
tg3_set_mtu(dev, tp, new_mtu);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
@@ -5740,7 +5740,7 @@ static int tg3_set_mac_addr(struct net_d
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
tg3_full_unlock(tp);
@@ -5798,7 +5798,7 @@ static void __tg3_set_coalesce(struct tg
}
/* tp->lock is held. */
-static int tg3_reset_hw(struct tg3 *tp)
+static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
{
u32 val, rdmac_mode;
int i, err, limit;
@@ -5813,7 +5813,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tg3_abort_hw(tp, 1);
}
- if (tp->tg3_flags2 & TG3_FLG2_MII_SERDES)
+ if ((tp->tg3_flags2 & TG3_FLG2_MII_SERDES) && reset_phy)
tg3_phy_reset(tp);
err = tg3_chip_reset(tp);
@@ -6354,7 +6354,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl);
}
- err = tg3_setup_phy(tp, 1);
+ err = tg3_setup_phy(tp, reset_phy);
if (err)
return err;
@@ -6427,7 +6427,7 @@ static int tg3_reset_hw(struct tg3 *tp)
/* Called at device open time to get the chip ready for
* packet processing. Invoked with tp->lock held.
*/
-static int tg3_init_hw(struct tg3 *tp)
+static int tg3_init_hw(struct tg3 *tp, int reset_phy)
{
int err;
@@ -6440,7 +6440,7 @@ static int tg3_init_hw(struct tg3 *tp)
tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
- err = tg3_reset_hw(tp);
+ err = tg3_reset_hw(tp, reset_phy);
out:
return err;
@@ -6710,7 +6710,7 @@ static int tg3_test_msi(struct tg3 *tp)
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
tg3_full_unlock(tp);
@@ -6775,7 +6775,7 @@ static int tg3_open(struct net_device *d
tg3_full_lock(tp, 0);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
if (err) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
tg3_free_rings(tp);
@@ -7866,7 +7866,7 @@ static int tg3_set_ringparam(struct net_
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -7911,7 +7911,7 @@ static int tg3_set_pauseparam(struct net
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -8549,7 +8549,7 @@ static int tg3_test_loopback(struct tg3
if (!netif_running(tp->dev))
return TG3_LOOPBACK_FAILED;
- tg3_reset_hw(tp);
+ tg3_reset_hw(tp, 1);
if (tg3_run_loopback(tp, TG3_MAC_LOOPBACK))
err |= TG3_MAC_LOOPBACK_FAILED;
@@ -8623,7 +8623,7 @@ static void tg3_self_test(struct net_dev
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
if (netif_running(dev)) {
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -11599,7 +11599,7 @@ static int tg3_suspend(struct pci_dev *p
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
@@ -11633,7 +11633,7 @@ static int tg3_resume(struct pci_dev *pd
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
^ permalink raw reply related
* [PATCH 3/6] tg3: Reset chip when changing MAC address
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Do the full chip reset when changing MAC address if ASF is enabled.
ASF sometimes uses a different MAC address than the driver. Without
the reset, the ASF MAC address may be overwritten when the driver's
MAC address is changed.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a307340..0ccfb63 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5732,9 +5732,23 @@ static int tg3_set_mac_addr(struct net_d
if (!netif_running(dev))
return 0;
- spin_lock_bh(&tp->lock);
- __tg3_set_mac_addr(tp);
- spin_unlock_bh(&tp->lock);
+ if (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) {
+ /* Reset chip so that ASF can re-init any MAC addresses it
+ * needs.
+ */
+ tg3_netif_stop(tp);
+ tg3_full_lock(tp, 1);
+
+ tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
+ tg3_init_hw(tp);
+
+ tg3_netif_start(tp);
+ tg3_full_unlock(tp);
+ } else {
+ spin_lock_bh(&tp->lock);
+ __tg3_set_mac_addr(tp);
+ spin_unlock_bh(&tp->lock);
+ }
return 0;
}
^ permalink raw reply related
* [PATCH 2/6] tg3: Add phy workaround
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Add some PHY workaround code to reduce jitter on some PHYs.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a28accb..a307340 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1030,6 +1030,12 @@ out:
tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x14e2);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
}
+ else if (tp->tg3_flags2 & TG3_FLG2_PHY_JITTER_BUG) {
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0c00);
+ tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x000a);
+ tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x010b);
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
+ }
/* Set Extended packet length bit (bit 14) on all chips that */
/* support jumbo frames */
if ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401) {
@@ -10360,10 +10366,13 @@ static int __devinit tg3_get_invariants(
if (tp->pci_chip_rev_id == CHIPREV_ID_5704_A0)
tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG;
- if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) &&
- (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5755) &&
- (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5787))
- tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) {
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5755 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5787)
+ tp->tg3_flags2 |= TG3_FLG2_PHY_JITTER_BUG;
+ else
+ tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ }
tp->coalesce_mode = 0;
if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX &&
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 8c8b987..0e29b88 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2215,6 +2215,7 @@ struct tg3 {
#define TG3_FLG2_HW_TSO_2 0x08000000
#define TG3_FLG2_HW_TSO (TG3_FLG2_HW_TSO_1 | TG3_FLG2_HW_TSO_2)
#define TG3_FLG2_1SHOT_MSI 0x10000000
+#define TG3_FLG2_PHY_JITTER_BUG 0x20000000
u32 split_mode_max_reqs;
#define SPLIT_MODE_5704_MAX_REQ 3
^ permalink raw reply related
* [PATCH 1/6] tg3: Call netif_carrier_off() during phy reset
From: Michael Chan @ 2006-04-28 23:35 UTC (permalink / raw)
To: davem; +Cc: netdev
Add netif_carrier_off() call during tg3_phy_reset(). This is needed
to properly track the netif_carrier state in cases where we do a
PHY reset with interrupts disabled. The SerDes code will not run
properly if the netif_carrier state is wrong.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 73e271e..a28accb 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -974,6 +974,8 @@ static int tg3_phy_reset_5703_4_5(struct
return err;
}
+static void tg3_link_report(struct tg3 *);
+
/* This will reset the tigon3 PHY if there is no valid
* link unless the FORCE argument is non-zero.
*/
@@ -987,6 +989,11 @@ static int tg3_phy_reset(struct tg3 *tp)
if (err != 0)
return -EBUSY;
+ if (netif_running(tp->dev) && netif_carrier_ok(tp->dev)) {
+ netif_carrier_off(tp->dev);
+ tg3_link_report(tp);
+ }
+
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) {
^ permalink raw reply related
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Jouni Malinen @ 2006-04-29 0:31 UTC (permalink / raw)
To: Larry Finger; +Cc: Rick Jones, Christoph Hellwig, netdev
In-Reply-To: <44501647.8070308@lwfinger.net>
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I don't think it would make that much difference as the user could easily
> lie about their locality and get any set of parameters that they wanted.
Well, not any set.. One of the configured countries, yes, but that is
not same as setting arbitrary TX power limit and allowed channel sets..
Anyway, users should be allowed to move from one country to another and
still being able to use their wlan card (within the limits of the
current location).
> I am leaning toward putting the geographical information into a userland
> daemon. That way we won't have to patch the kernel every time a country
> modifies its regulations. In addition, the kernel will be smaller. The
> downside is that the daemon will have to be updated and supplied in some
> convenient form, perhaps as part of a wireless tools package.
I'm strongly in favor of doing this in user space, too. In order to
provide some control on what end users do with this, I would consider
including a signature on a data file and have the user space tool verify
that signature before accepting the data. This signature need not be
anything extra secure, i.e., it could just be a keyed checksum of the
file using a well-known key. The main point here is that it shows some
attempt on limiting end users from setting random values to regulatory
limits. Of course, if someone really wants to change these values, they
could do so since the source code for the tool would be available and so
would the key used for signing the file in the first place.
I don't know how secure a system would be needed to pass requirements
that FCC and similar organizations place on wireless devices. I would
like to handle this with fully open source tools and having some kind of
simple signature on the data file would be good starting point. It is up
to vendors then to decide whether they are fine with such a mechanism or
whether some additional tool (like the Intel plan on using a closed
source user space tool) would be needed on top of this.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-29 0:22 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.154003.25335370.davem@davemloft.net>
On Fri, 2006-04-28 at 15:40 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Sat, 29 Apr 2006 08:17:01 +1000
> > However, in future, if intelligent cards exist, having an API which lets
> > them do zero-copy and not overly penalize less intelligent cards makes
> > sense.
>
> I do not think intelligent cards imply protocol in user space.
> You can still get the zero copy, and moving the work to the
> remote cpu, without all the complexity assosciated with putting
> the protocol in userspace. It buys nothing but complexity.
You're thinking the card would place the packet in the mmap'ed buffer,
but the protocol handling would still be done (on that user-accessible
buffer) in kernelspace?
I hadn't considered that. Are the userspace-kernel interactions here
are a lesser problem than telling userspace "you want direct access to
the packets? Great, *you* handle the whole thing".
I am thinking the big payoff for this would be MPI et al (RDMA), so we
might be best leaving it alone.
> > Side note: my Xen I/O patches allow the implementation of exactly this
> > kind of virtual hardware (no coincidence 8), so intelligent cards might
> > not be as far away as you think...
>
> Such hardware can be prototyped in QEMU as well.
Absolutely (and writing QEMU devices is easier than writing a Linux
device driver, which says something sad).
But the Xen virtual intelligent NIC would be a "real" NIC, not (just) a
prototype.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-29 0:10 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.153833.68265167.davem@davemloft.net>
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
> > You're still thinking you can bypass classifiers for established
> > sockets, but I really don't think you can. I think the simplest
> > solution is to effectively remove from (or flag) the established &
> > listening hashes anything which could be effected by classifiers, so
> > those packets get send through the default channel.
>
> OK, when rules are installed, the socket channel mappings are
> flushed. This is your idea right?
Yeah. First off, all flushed. Later on, we get selective.
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: Nuri Jawad @ 2006-04-29 0:05 UTC (permalink / raw)
To: Sven Schuster; +Cc: Andi Kleen, Jesse Brandeburg, Andrew Morton, netdev
In-Reply-To: <20060426060442.GA8875@zion.homelinux.com>
On Wed, 26 Apr 2006, Sven Schuster wrote:
> but don't hold your breath waiting for me, kernel compile
> takes more than two hours on my box :-)
Ouch. Takes 5/7 minutes here on the AMD64 resp. P4. Computer museum? :P
Anyhow, I tested PPP for 2.5 hours on the AMD64 the day before
yesterday with a bidirectional transfer that maxed out the upstream.
Last night, I additionally put some load on the CPU. Another 3 hours, no
problems whatsoever. Looks like the bug does not manifest on that system.
The next step will be to clone .config's settings as far as possible with
the different hardware and try again.
Regards,
Nuri
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 23:45 UTC (permalink / raw)
To: David S. Miller, rusty; +Cc: johnpol, kelly, netdev
David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Sat, 29 Apr 2006 08:04:04 +1000
>
>> You're still thinking you can bypass classifiers for established
>> sockets, but I really don't think you can. I think the simplest
>> solution is to effectively remove from (or flag) the established &
>> listening hashes anything which could be effected by classifiers, so
>> those packets get send through the default channel.
>
> OK, when rules are installed, the socket channel mappings are
> flushed. This is your idea right?
You mean when new rules are installed that would conflict with
an existing mapping, right?
Bumping every connection out of vj-channel mode whenever any new
rule was installed would be very counter-productive.
Ultimately, you only want a direct-to-user vj-channel when all
packets assigned to it would be passed by netchannels, and maybe
increment a single packet counter. Checking a single QoS rate
limiter may be possible too, but if there are more complex
rules then the channel has to be kept in kernel because it
wouldn't make sense to trust user-mode code to apply the
netchannel rules reliably.
^ permalink raw reply
* Re: [PATCH] fix unlikely usage in tcp_transmit_skb()
From: Alexey Toptygin @ 2006-04-28 23:45 UTC (permalink / raw)
To: David S. Miller; +Cc: hzhong, netdev
In-Reply-To: <20060428.152551.50641016.davem@davemloft.net>
On Fri, 28 Apr 2006, David S. Miller wrote:
> From: Hua Zhong <hzhong@gmail.com>
> Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
>
>> [I hope this time it's OK - I'm sending from pine/Linux]
>
> It adds an extra space in the diff lines which corrupts
> the patch.
You can work around this by enabling quell-flowed-text - then pine will
never mangle patches. Currently (pine4.64), if you're disabling flowed
text on a per-message basis with ^V before sending, patches containing
trailing whitespace will get mangled. Pine labels the message as not
flowed, but does the mangling anyway :-/
Tooting my own horn here, but I submitted a pine patch this week which
fixes the issue. Hopefully, the next pine release will behave correctly.
You'll still have to remember to hit ^V before sending mail containing
patches, and you should always use ^R to include patch files, since
newlines in the input are treated magically. Or, you can enable
quell-flowed-text, and pretend the whole flowed text feature never
happened. I'll shut up about pine now :-)
Alexey
^ permalink raw reply
* Re: [RFC PATCH] [IPV6]: Fix race in route selection.
From: David S. Miller @ 2006-04-28 22:58 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20060428.020456.35552581.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 28 Apr 2006 02:04:56 +0900 (JST)
> We eliminated rt6_dflt_lock (to protect default router pointer)
> at 2.6.17-rc1, and introduced rt6_select() for general router selection.
> The function is called in the context of rt6_lock read-lock held,
> but this means, we have some race conditions when we do round-robin.
>
> Am I correct?
>
> If so, we should put some spin_lock for serialization.
>
> Comments?
>
> Signed-off-by; YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> Or, should we run whole part of rt6_select() under some lock?
I think the local lock will work and it is fine for now.
I will apply this as-is to fix the bug.
But in the longer term this seems a little bit heavy operation.
Perhaps there is some way to use "xchg()" here? It is just moving a
pointer around for a round robin list, if it could be reduced to just
a single pointer store, we could even do it without atomic operations.
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Harald Welte @ 2006-04-28 11:17 UTC (permalink / raw)
To: Larry Finger; +Cc: Rick Jones, Christoph Hellwig, netdev
In-Reply-To: <44501647.8070308@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I am leaning toward putting the geographical information into a
> userland daemon.
I like that idea very much. This is all control metadate that doesn't
really need to be in the kernel.
> That way we won't have to patch the kernel every time a country
> modifies its regulations.
that's another advantage.
> In addition, the kernel will be smaller. The downside is that the
> daemon will have to be updated and supplied in some convenient form,
> perhaps as part of a wireless tools package.
Ideally the daemon would get the table of country restrictions from a
policy file (some human-readable ascii?). That file can then be
downloaded by a cronjob to keep it updated, if desired. A bit like the
PCI/USB device id databases...
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:40 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146262622.8029.63.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sat, 29 Apr 2006 08:17:01 +1000
> On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> > vj_netchannels represent a strategy of minimizing
> > registration/pinning costs even if it means paying for an extra copy.
> > Because the extra copy is closely tied to the activation of the data
> > sink consumer the cost of that extra copy is greatly reduced because
> > it places the data in the cache immediately before the application
> > will in fact use the received data.
>
> Just to be clear here: I agree with Dave that without classifying
> hardware, there's no point (and much pain) in going all the way to
> userspace with the channel (ie. mmap). If you're going to copy anyway,
> might as well do it in the socket's read() call: then the user can then
> aim the copy exactly where they want, too. We'll need that TCP code in
> the kernel for the foreseeable future anyway 8)
>
> However, in future, if intelligent cards exist, having an API which lets
> them do zero-copy and not overly penalize less intelligent cards makes
> sense.
I do not think intelligent cards imply protocol in user space.
You can still get the zero copy, and moving the work to the
remote cpu, without all the complexity assosciated with putting
the protocol in userspace. It buys nothing but complexity.
> Side note: my Xen I/O patches allow the implementation of exactly this
> kind of virtual hardware (no coincidence 8), so intelligent cards might
> not be as far away as you think...
Such hardware can be prototyped in QEMU as well.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:38 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146261844.8029.54.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sat, 29 Apr 2006 08:04:04 +1000
> You're still thinking you can bypass classifiers for established
> sockets, but I really don't think you can. I think the simplest
> solution is to effectively remove from (or flag) the established &
> listening hashes anything which could be effected by classifiers, so
> those packets get send through the default channel.
OK, when rules are installed, the socket channel mappings are
flushed. This is your idea right?
^ permalink raw reply
* Re: [PATCH] fix unlikely usage in tcp_transmit_skb()
From: David S. Miller @ 2006-04-28 22:25 UTC (permalink / raw)
To: hzhong; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0604260947040.2907@localhost.localdomain>
From: Hua Zhong <hzhong@gmail.com>
Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
> [I hope this time it's OK - I'm sending from pine/Linux]
It adds an extra space in the diff lines which corrupts
the patch.
I've applied this by hand, but please try to get something
which works before providing new patches. Just try to email
yourself a patch, then try to apply it successfully yourself.
Thanks.
^ permalink raw reply
* Re: [IPSEC]: Fix IP ID selection
From: David S. Miller @ 2006-04-28 22:23 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060427115645.GA20140@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 27 Apr 2006 21:56:45 +1000
> I was looking through the xfrm input/output code in order to abstract
> out the address family specific encapsulation/decapsulation code. During
> that process I found this bug in the IP ID selection code in xfrm4_output.c.
>
> At that point dst is still the xfrm_dst for the current SA which
> represents an internal flow as far as the IPsec tunnel is concerned.
> Since the IP ID is going to sit on the outside of the encapsulated
> packet, we obviously want the external flow which is just dst->child.
>
> The fix is trivial.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks for catching this, applied, thanks Herbert.
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-28 22:17 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Evgeniy Polyakov, David S. Miller, kelly, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B10A@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> vj_netchannels represent a strategy of minimizing
> registration/pinning costs even if it means paying for an extra copy.
> Because the extra copy is closely tied to the activation of the data
> sink consumer the cost of that extra copy is greatly reduced because
> it places the data in the cache immediately before the application
> will in fact use the received data.
Just to be clear here: I agree with Dave that without classifying
hardware, there's no point (and much pain) in going all the way to
userspace with the channel (ie. mmap). If you're going to copy anyway,
might as well do it in the socket's read() call: then the user can then
aim the copy exactly where they want, too. We'll need that TCP code in
the kernel for the foreseeable future anyway 8)
However, in future, if intelligent cards exist, having an API which lets
them do zero-copy and not overly penalize less intelligent cards makes
sense.
Side note: my Xen I/O patches allow the implementation of exactly this
kind of virtual hardware (no coincidence 8), so intelligent cards might
not be as far away as you think...
> Also keep in mind that once the issues are resolved to allow the
> netchannel rings to be directly visible to a user-mode client that
> enhanced/specialized interfaces can easily be added in user-mode
> libraries. So focusing on supporting existing conventional interfaces
> is probably the best approach for the initial efforts.
Absolutely.
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-04-28 22:04 UTC (permalink / raw)
To: David S. Miller; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <20060428.122102.76435590.davem@davemloft.net>
On Fri, 2006-04-28 at 12:21 -0700, David S. Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Fri, 28 Apr 2006 18:24:08 +1000
>
> > Note that the problem space AFAICT includes strange advanced routing
> > setups, ingress qos and possibly others, not just netfilter. But
> > perhaps the same solutions apply, so I'll concentrate on nf.
>
> Yes, this hasn't been mentioned explicitly yet.
>
> The big problem is that we don't want the classifier to become
> overly complex.
>
> One scheme I'm thinking about right now is an ordered lookup
> that looks like:
>
> 1) Check for established sockets, they trump everything else.
>
> 2) Check for classifier rules, ie. netfilter and packet scheduler
> stuff
>
> 3) Check for listening sockets
>
> 4) default channel
>
> #2 is still an unsolved problem, we don't want this big complex
> classifier to be required in the hardware implementations.
> However, using just IP addresses and ports does not map well to
> what netfilter and co. want.
You're still thinking you can bypass classifiers for established
sockets, but I really don't think you can. I think the simplest
solution is to effectively remove from (or flag) the established &
listening hashes anything which could be effected by classifiers, so
those packets get send through the default channel.
This can graduate from "all or nothing" to some more fine-grained scheme
over time. I have some early thoughts on how we could really do this
with filtering by connection tracking state; serious work, but feasible.
> > Ah, this is a different problem. Our idea was to have a syscall which
> > would check & sanitize the buffers for output. To do this, you need the
> > ability to chain buffers (a simple next entry in the header, for us).
> >
> > Sanitization would copy the header into a global buffer (ie. not one
> > reachable by userspace), check the flowid, and chain on the rest of the
> > user buffer. After it had sanitized the buffers, it would activate the
> > NIC, which would only send out buffers which started with a kernel
> > buffer.
> >
> > Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And,
> > if the "sanitize_and_send" syscall were PF_VJCHAN's write(), then the
> > contents of the write() could actually be the header: userspace would
> > never deal with chained buffers.
>
> I am not sure any of this is anything more than overhead.
>
> If we just pop the buffers directly into the user mmap()'d ring
> buffer, headers and all, and give an offset+length pair so the
> user knows where the data starts and how much data is there, it
> should all just work out. Where to put the offset+length is
> just a detail.
Agreed, but I was talking about userspace *send*, in reply to Caitlin
bringing it up. A little off-topic, but I mentioned our thoughts simply
to show that it's possible to do unpriv'ed output...
(Kelly is taking a couple of well-earned days off ATM).
Cheers!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 22:00 UTC (permalink / raw)
To: johnpol; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428195930.GB21294@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 23:59:30 +0400
> kevent can be used as poll without any changes to the socket code.
> There are two types of network related kevents - socket events
> (recv/send/accept) and network aio, which can be turned completely off
> in config.
> There are following events which are supported by kevent:
> o usual poll/select notifications
> o inode notifications (create/remove)
> o timer notifications
> o socket notifications (send/recv/accept)
> o network aio system
> o fs aio (project closed, aio_sendfile() is being developed instead)
>
> Any of the above can be turned off by config option.
Feel free to post the current version of your kevent patch
here so we can discuss something concrete.
Maybe you have even some toy example user applications that
use kevent that people can look at too? That might help
in understanding how it's supposed to be used.
^ permalink raw reply
* Re: [patch] cleanup unused macro in net/netlink/af_netlink.c
From: David S. Miller @ 2006-04-28 21:59 UTC (permalink / raw)
To: speattle; +Cc: netdev
In-Reply-To: <20060428205143.20727.qmail@web36613.mail.mud.yahoo.com>
From: S P <speattle@yahoo.com>
Date: Fri, 28 Apr 2006 13:51:43 -0700 (PDT)
> 1 line removal, of unused macro.
> ran 'egrep -r' from linux-2.6.16/ for Nprintk and
> didn't see it anywhere else but here, in #define...
>
> ------------------------------------------------
> signed off by: soyoung park<speattle@yahoo.com>
Patch applied, thanks a lot.
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Gómez @ 2006-04-28 21:58 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.58.0604281458110.19801@sbz-30.cs.Helsinki.FI>
Hi Pekka,
On Apr 28 at 02:59:01, Pekka J Enberg wrote:
> Here are some suggestions for coding style cleanups:
Couple of questions,
> - Use dev_{dbg,err,info,warn} for logging
Cannot, i need a "struct device" and most of the
there's only access to a "struct net_device". Am i
missing something?
> - Use proper naming convention for things like Length and pPHYParam
What's the convention for these names?
Thanks,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* Re: [PATCH] ibmveth change buffer pools dynamically
From: Santiago Leon @ 2006-04-28 21:53 UTC (permalink / raw)
To: jgarzik, netdev
In-Reply-To: <1145981998.16266.5.camel@santilt>
Santiago Leon wrote:
> This patch provides a sysfs interface to change some properties of the
> ibmveth buffer pools (size of the buffers, number of buffers per pool,
> and whether a pool is active). Ethernet drivers use ethtool to provide
> this type of functionality. However, the buffers in the ibmveth driver
> can have an arbitrary size (not only regular, mini, and jumbo which are
> the only sizes that ethtool can change), and also ibmveth can have an
> arbitrary number of buffer pools
>
> Under heavy load we have seen dropped packets which obviously kills TCP
> performance. We have created several fixes that mitigate this issue,
> but we definitely need a way of changing the number of buffers for an
> adapter dynamically. Also, changing the size of the buffers allows
> users to change the MTU to something big (bigger than a jumbo frame)
> greatly improving performance on partition to partition transfers.
>
> The patch creates directories pool1...pool4 in the device directory in
> sysfs, each with files: num, size, and active (which default to the
> values in the mainline version).
>
> Comments and suggestions are welcome...
>
Jeff, if you don't have any problem with this patch, can you apply it?
Thanks,
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] ibmveth support for netpoll
From: Santiago Leon @ 2006-04-28 21:53 UTC (permalink / raw)
To: jgarzik, netdev
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
This patch adds NETPOLL support for the ibmveth driver. Please apply.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
ibmveth.c | 11 +++++++++++
1 file changed, 11 insertions(+)
[-- Attachment #2: ibmveth_netpoll.patch --]
[-- Type: text/plain, Size: 884 bytes --]
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:17:59.971778584 -0500
@@ -918,6 +918,14 @@ static int ibmveth_change_mtu(struct net
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void ibmveth_poll_controller(struct net_device *dev)
+{
+ ibmveth_replenish_task(dev->priv);
+ ibmveth_interrupt(dev->irq, dev, NULL);
+}
+#endif
+
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
@@ -989,6 +997,9 @@ static int __devinit ibmveth_probe(struc
netdev->ethtool_ops = &netdev_ethtool_ops;
netdev->change_mtu = ibmveth_change_mtu;
SET_NETDEV_DEV(netdev, &dev->dev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev->poll_controller = ibmveth_poll_controller;
+#endif
netdev->features |= NETIF_F_LLTX;
spin_lock_init(&adapter->stats_lock);
^ permalink raw reply
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