* Re: SFQ: Reordering?
From: Andy Furniss @ 2005-05-09 23:14 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Thomas Graf, Asim Shankar, netdev
In-Reply-To: <427C19C3.5030304@trash.net>
Patrick McHardy wrote:
> It would be interesting to see this in real-life, when a single flow
> is hashed to multiple buckets (it can be even more than two) and
> each bucket has some packets queued, the result should look pretty
> chaotic.
It certainly hurts latency if used for ingress shaping, perturb nearly
always makes the sender backoff and then burst.
Andy.
^ permalink raw reply
* Re: [TG3]: Add tagged status support
From: David S. Miller @ 2005-05-09 22:54 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1115675082.8570.10.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Subject: Re: [TG3]: Add tagged status support
Date: Mon, 09 May 2005 14:44:42 -0700
> I found one typo during testing, flags2 should have been flags:
>
> + if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
Good catch, fixed.
> I think it will be better to move up this block of code because here we
> are at the point of returning error from tg3_open().
I agree. Here is the updated version of the patch.
[TG3]: Add tagged status support.
When supported, use the TAGGED interrupt processing support
the chip provides. In this mode, instead of a "on/off" binary
semaphore, an incrementing tag scheme is used to ACK interrupts.
All MSI supporting chips support TAGGED mode, so the tg3_msi()
interrupt handler uses it unconditionally. This invariant is
verified when MSI support is tested.
Since we can invoke tg3_poll() multiple times per interrupt under
high packet load, we fetch a new copy of the tag value in the
status block right before we actually do the work.
Also, because the tagged status tells the chip exactly which
work we have processed, we can make two optimizations:
1) tg3_restart_ints() need not check tg3_has_work()
2) the tg3_timer() need not poke the chip 10 times per
second to keep from losing interrupt events
Based upon valuable feedback from Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
--- 1/drivers/net/tg3.c.~1~ 2005-05-09 15:51:29.000000000 -0700
+++ 2/drivers/net/tg3.c 2005-05-09 15:52:32.000000000 -0700
@@ -420,7 +420,8 @@ static void tg3_enable_ints(struct tg3 *
{
tw32(TG3PCI_MISC_HOST_CTRL,
(tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT));
- tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ (tp->last_tag << 24));
tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
tg3_cond_int(tp);
@@ -455,10 +456,16 @@ static void tg3_restart_ints(struct tg3
{
tw32(TG3PCI_MISC_HOST_CTRL,
(tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT));
- tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ tp->last_tag << 24);
mmiowb();
- if (tg3_has_work(tp))
+ /* When doing tagged status, this work check is unnecessary.
+ * The last_tag we write above tells the chip which piece of
+ * work we've completed.
+ */
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) &&
+ tg3_has_work(tp))
tw32(HOSTCC_MODE, tp->coalesce_mode |
(HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
}
@@ -2862,6 +2869,9 @@ static int tg3_poll(struct net_device *n
spin_lock_irqsave(&tp->lock, flags);
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ tp->last_tag = sblk->status_tag;
+
/* handle link change and other phy events */
if (!(tp->tg3_flags &
(TG3_FLAG_USE_LINKCHG_REG |
@@ -2928,22 +2938,21 @@ static irqreturn_t tg3_msi(int irq, void
spin_lock_irqsave(&tp->lock, flags);
/*
- * writing any value to intr-mbox-0 clears PCI INTA# and
+ * Writing any value to intr-mbox-0 clears PCI INTA# and
* chip-internal interrupt pending events.
- * writing non-zero to intr-mbox-0 additional tells the
+ * Writing non-zero to intr-mbox-0 additional tells the
* NIC to stop sending us irqs, engaging "in-intr-handler"
* event coalescing.
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001);
+ tp->last_tag = sblk->status_tag;
sblk->status &= ~SD_STATUS_UPDATED;
-
if (likely(tg3_has_work(tp)))
netif_rx_schedule(dev); /* schedule NAPI poll */
else {
- /* no work, re-enable interrupts
- */
+ /* No work, re-enable interrupts. */
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
- 0x00000000);
+ tp->last_tag << 24);
}
spin_unlock_irqrestore(&tp->lock, flags);
@@ -2969,21 +2978,62 @@ static irqreturn_t tg3_interrupt(int irq
if ((sblk->status & SD_STATUS_UPDATED) ||
!(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) {
/*
- * writing any value to intr-mbox-0 clears PCI INTA# and
+ * Writing any value to intr-mbox-0 clears PCI INTA# and
* chip-internal interrupt pending events.
- * writing non-zero to intr-mbox-0 additional tells the
+ * Writing non-zero to intr-mbox-0 additional tells the
* NIC to stop sending us irqs, engaging "in-intr-handler"
* event coalescing.
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
0x00000001);
+ sblk->status &= ~SD_STATUS_UPDATED;
+ if (likely(tg3_has_work(tp)))
+ netif_rx_schedule(dev); /* schedule NAPI poll */
+ else {
+ /* No work, shared interrupt perhaps? re-enable
+ * interrupts, and flush that PCI write
+ */
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ 0x00000000);
+ tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ }
+ } else { /* shared interrupt */
+ handled = 0;
+ }
+
+ spin_unlock_irqrestore(&tp->lock, flags);
+
+ return IRQ_RETVAL(handled);
+}
+
+static irqreturn_t tg3_interrupt_tagged(int irq, void *dev_id, struct pt_regs *regs)
+{
+ struct net_device *dev = dev_id;
+ struct tg3 *tp = netdev_priv(dev);
+ struct tg3_hw_status *sblk = tp->hw_status;
+ unsigned long flags;
+ unsigned int handled = 1;
+
+ spin_lock_irqsave(&tp->lock, flags);
+
+ /* In INTx mode, it is possible for the interrupt to arrive at
+ * the CPU before the status block posted prior to the interrupt.
+ * Reading the PCI State register will confirm whether the
+ * interrupt is ours and will flush the status block.
+ */
+ if ((sblk->status & SD_STATUS_UPDATED) ||
+ !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) {
/*
- * Flush PCI write. This also guarantees that our
- * status block has been flushed to host memory.
+ * writing any value to intr-mbox-0 clears PCI INTA# and
+ * chip-internal interrupt pending events.
+ * writing non-zero to intr-mbox-0 additional tells the
+ * NIC to stop sending us irqs, engaging "in-intr-handler"
+ * event coalescing.
*/
- tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ 0x00000001);
+ tp->last_tag = sblk->status_tag;
sblk->status &= ~SD_STATUS_UPDATED;
-
if (likely(tg3_has_work(tp)))
netif_rx_schedule(dev); /* schedule NAPI poll */
else {
@@ -2991,7 +3041,7 @@ static irqreturn_t tg3_interrupt(int irq
* interrupts, and flush that PCI write
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
- 0x00000000);
+ tp->last_tag << 24);
tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
}
} else { /* shared interrupt */
@@ -5445,7 +5495,8 @@ static int tg3_reset_hw(struct tg3 *tp)
udelay(100);
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0);
- tr32(MAILBOX_INTERRUPT_0);
+ tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ tp->last_tag = 0;
if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
tw32_f(DMAC_MODE, DMAC_MODE_ENABLE);
@@ -5723,31 +5774,33 @@ static void tg3_timer(unsigned long __op
spin_lock_irqsave(&tp->lock, flags);
spin_lock(&tp->tx_lock);
- /* All of this garbage is because when using non-tagged
- * IRQ status the mailbox/status_block protocol the chip
- * uses with the cpu is race prone.
- */
- if (tp->hw_status->status & SD_STATUS_UPDATED) {
- tw32(GRC_LOCAL_CTRL,
- tp->grc_local_ctrl | GRC_LCLCTRL_SETINT);
- } else {
- tw32(HOSTCC_MODE, tp->coalesce_mode |
- (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
- }
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
+ /* All of this garbage is because when using non-tagged
+ * IRQ status the mailbox/status_block protocol the chip
+ * uses with the cpu is race prone.
+ */
+ if (tp->hw_status->status & SD_STATUS_UPDATED) {
+ tw32(GRC_LOCAL_CTRL,
+ tp->grc_local_ctrl | GRC_LCLCTRL_SETINT);
+ } else {
+ tw32(HOSTCC_MODE, tp->coalesce_mode |
+ (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
+ }
- if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) {
- tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER;
- spin_unlock(&tp->tx_lock);
- spin_unlock_irqrestore(&tp->lock, flags);
- schedule_work(&tp->reset_task);
- return;
+ if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) {
+ tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER;
+ spin_unlock(&tp->tx_lock);
+ spin_unlock_irqrestore(&tp->lock, flags);
+ schedule_work(&tp->reset_task);
+ return;
+ }
}
- if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
- tg3_periodic_fetch_stats(tp);
-
/* This part only runs once per second. */
if (!--tp->timer_counter) {
+ if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
+ tg3_periodic_fetch_stats(tp);
+
if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) {
u32 mac_stat;
int phy_event;
@@ -5846,9 +5899,13 @@ static int tg3_test_interrupt(struct tg3
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI)
err = request_irq(tp->pdev->irq, tg3_msi,
SA_SAMPLE_RANDOM, dev->name, dev);
- else
- err = request_irq(tp->pdev->irq, tg3_interrupt,
+ else {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+ err = request_irq(tp->pdev->irq, fn,
SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err)
return err;
@@ -5900,9 +5957,14 @@ static int tg3_test_msi(struct tg3 *tp)
tp->tg3_flags2 &= ~TG3_FLG2_USING_MSI;
- err = request_irq(tp->pdev->irq, tg3_interrupt,
- SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+ err = request_irq(tp->pdev->irq, fn,
+ SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err)
return err;
@@ -5948,7 +6010,13 @@ static int tg3_open(struct net_device *d
if ((tp->tg3_flags2 & TG3_FLG2_5750_PLUS) &&
(GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_AX) &&
(GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_BX)) {
- if (pci_enable_msi(tp->pdev) == 0) {
+ /* All MSI supporting chips should support tagged
+ * status. Assert that this is the case.
+ */
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
+ printk(KERN_WARNING PFX "%s: MSI without TAGGED? "
+ "Not using MSI.\n", tp->dev->name);
+ } else if (pci_enable_msi(tp->pdev) == 0) {
u32 msi_mode;
msi_mode = tr32(MSGINT_MODE);
@@ -5959,9 +6027,14 @@ static int tg3_open(struct net_device *d
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI)
err = request_irq(tp->pdev->irq, tg3_msi,
SA_SAMPLE_RANDOM, dev->name, dev);
- else
- err = request_irq(tp->pdev->irq, tg3_interrupt,
+ else {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+
+ err = request_irq(tp->pdev->irq, fn,
SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err) {
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
@@ -5980,9 +6053,16 @@ static int tg3_open(struct net_device *d
tg3_halt(tp, 1);
tg3_free_rings(tp);
} else {
- tp->timer_offset = HZ / 10;
- tp->timer_counter = tp->timer_multiplier = 10;
- tp->asf_counter = tp->asf_multiplier = (10 * 120);
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ tp->timer_offset = HZ;
+ else
+ tp->timer_offset = HZ / 10;
+
+ BUG_ON(tp->timer_offset > HZ);
+ tp->timer_counter = tp->timer_multiplier =
+ (HZ / tp->timer_offset);
+ tp->asf_counter = tp->asf_multiplier =
+ ((HZ / tp->timer_offset) * 120);
init_timer(&tp->timer);
tp->timer.expires = jiffies + tp->timer_offset;
@@ -6005,6 +6085,7 @@ static int tg3_open(struct net_device *d
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
err = tg3_test_msi(tp);
+
if (err) {
spin_lock_irq(&tp->lock);
spin_lock(&tp->tx_lock);
@@ -8422,15 +8503,7 @@ static int __devinit tg3_get_invariants(
if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
- /* Only 5701 and later support tagged irq status mode.
- * Also, 5788 chips cannot use tagged irq status.
- *
- * However, since we are using NAPI avoid tagged irq status
- * because the interrupt condition is more difficult to
- * fully clear in that mode.
- */
tp->coalesce_mode = 0;
-
if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX &&
GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_BX)
tp->coalesce_mode |= HOSTCC_MODE_32BYTE;
@@ -8494,6 +8567,18 @@ static int __devinit tg3_get_invariants(
grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M))
tp->tg3_flags2 |= TG3_FLG2_IS_5788;
+ if (!(tp->tg3_flags2 & TG3_FLG2_IS_5788) &&
+ (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700))
+ tp->tg3_flags |= TG3_FLAG_TAGGED_STATUS;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) {
+ tp->coalesce_mode |= (HOSTCC_MODE_CLRTICK_RXBD |
+ HOSTCC_MODE_CLRTICK_TXBD);
+
+ tp->misc_host_ctrl |= MISC_HOST_CTRL_TAGGED_STATUS;
+ pci_write_config_dword(tp->pdev, TG3PCI_MISC_HOST_CTRL,
+ tp->misc_host_ctrl);
+ }
+
/* these are limited to 10/100 only */
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 &&
(grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) ||
--- 1/drivers/net/tg3.h.~1~ 2005-05-09 15:51:32.000000000 -0700
+++ 2/drivers/net/tg3.h 2005-05-09 15:51:40.000000000 -0700
@@ -2023,6 +2023,7 @@ struct tg3 {
struct tg3_hw_status *hw_status;
dma_addr_t status_mapping;
+ u32 last_tag;
u32 msg_enable;
@@ -2068,6 +2069,7 @@ struct tg3 {
u32 rx_offset;
u32 tg3_flags;
+#define TG3_FLAG_TAGGED_STATUS 0x00000001
#define TG3_FLAG_TXD_MBOX_HWBUG 0x00000002
#define TG3_FLAG_RX_CHECKSUMS 0x00000004
#define TG3_FLAG_USE_LINKCHG_REG 0x00000008
^ permalink raw reply
* Re: [TG3]: Add tagged status support
From: Michael Chan @ 2005-05-09 21:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050509124832.2a073e11.davem@davemloft.net>
On Mon, 2005-05-09 at 12:48 -0700, David S. Miller wrote:
> Here is my current patch, how does it look.
>
> @@ -6005,6 +6079,16 @@ static int tg3_open(struct net_device *d
>
> if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
> err = tg3_test_msi(tp);
> +
> + /* All MSI supporting chips should support tagged
> + * status. Assert that this is the case.
> + */
> + if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) {
> + printk(KERN_WARNING PFX "%s: MSI without TAGGED? "
> + "Not using MSI.\n", tp->dev->name);
> + err = -EINVAL;
> + }
> +
> if (err) {
> spin_lock_irq(&tp->lock);
> spin_lock(&tp->tx_lock);
I found one typo during testing, flags2 should have been flags:
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
I think it will be better to move up this block of code because here we
are at the point of returning error from tg3_open().
Something like this:
diff -Nru h/drivers/net/tg3.c i/drivers/net/tg3.c
--- h/drivers/net/tg3.c 2005-05-09 14:12:37.000000000 -0700
+++ i/drivers/net/tg3.c 2005-05-09 14:24:19.000000000 -0700
@@ -6010,7 +6010,14 @@
if ((tp->tg3_flags2 & TG3_FLG2_5750_PLUS) &&
(GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_AX) &&
(GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5750_BX)) {
- if (pci_enable_msi(tp->pdev) == 0) {
+ /* All MSI supporting chips should support tagged
+ * status. Assert that this is the case.
+ */
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
+ printk(KERN_WARNING PFX "%s: MSI without TAGGED? "
+ "Not using MSI.\n", tp->dev->name);
+ }
+ else if (pci_enable_msi(tp->pdev) == 0) {
u32 msi_mode;
msi_mode = tr32(MSGINT_MODE);
@@ -6080,15 +6087,6 @@
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
err = tg3_test_msi(tp);
- /* All MSI supporting chips should support tagged
- * status. Assert that this is the case.
- */
- if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) {
- printk(KERN_WARNING PFX "%s: MSI without TAGGED? "
- "Not using MSI.\n", tp->dev->name);
- err = -EINVAL;
- }
-
if (err) {
spin_lock_irq(&tp->lock);
spin_lock(&tp->tx_lock);
^ permalink raw reply
* Re: [TG3]: Add tagged status support
From: David S. Miller @ 2005-05-09 19:48 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
In-Reply-To: <1115418431.15156.153.camel@rh4>
On Fri, 06 May 2005 15:27:11 -0700
"Michael Chan" <mchan@broadcom.com> wrote:
> I tested the patch and it worked fine. But I'd like to suggest a few
> things:
Thanks for the feedback. I decided that it's better to just test
the tg3 flag instead of make a special function pointer, since
the flag bits sit in the cpu cache all the time already and
the branches should be always predicted properly.
Here is my current patch, how does it look.
If there are no problems, we can integrate the hw coalescing bits
on top of this.
[TG3]: Add tagged status support.
When supported, use the TAGGED interrupt processing support
the chip provides. In this mode, instead of a "on/off" binary
semaphore, an incrementing tag scheme is used to ACK interrupts.
All MSI supporting chips support TAGGED mode, so the tg3_msi()
interrupt handler uses it unconditionally. This invariant is
verified when MSI support is tested.
Since we can invoke tg3_poll() multiple times per interrupt under
high packet load, we fetch a new copy of the tag value in the
status block right before we actually do the work.
Also, because the tagged status tells the chip exactly which
work we have processed, we can make two optimizations:
1) tg3_restart_ints() need not check tg3_has_work()
2) the tg3_timer() need not poke the chip 10 times per
second to keep from losing interrupt events
Based upon valuable feedback from Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
--- 1/drivers/net/tg3.c.~1~ 2005-05-05 17:15:59.000000000 -0700
+++ 2/drivers/net/tg3.c 2005-05-09 12:34:28.000000000 -0700
@@ -420,7 +420,8 @@ static void tg3_enable_ints(struct tg3 *
{
tw32(TG3PCI_MISC_HOST_CTRL,
(tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT));
- tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ (tp->last_tag << 24));
tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
tg3_cond_int(tp);
@@ -455,10 +456,16 @@ static void tg3_restart_ints(struct tg3
{
tw32(TG3PCI_MISC_HOST_CTRL,
(tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT));
- tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000000);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ tp->last_tag << 24);
mmiowb();
- if (tg3_has_work(tp))
+ /* When doing tagged status, this work check is unnecessary.
+ * The last_tag we write above tells the chip which piece of
+ * work we've completed.
+ */
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) &&
+ tg3_has_work(tp))
tw32(HOSTCC_MODE, tp->coalesce_mode |
(HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
}
@@ -2862,6 +2869,9 @@ static int tg3_poll(struct net_device *n
spin_lock_irqsave(&tp->lock, flags);
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ tp->last_tag = sblk->status_tag;
+
/* handle link change and other phy events */
if (!(tp->tg3_flags &
(TG3_FLAG_USE_LINKCHG_REG |
@@ -2928,22 +2938,21 @@ static irqreturn_t tg3_msi(int irq, void
spin_lock_irqsave(&tp->lock, flags);
/*
- * writing any value to intr-mbox-0 clears PCI INTA# and
+ * Writing any value to intr-mbox-0 clears PCI INTA# and
* chip-internal interrupt pending events.
- * writing non-zero to intr-mbox-0 additional tells the
+ * Writing non-zero to intr-mbox-0 additional tells the
* NIC to stop sending us irqs, engaging "in-intr-handler"
* event coalescing.
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001);
+ tp->last_tag = sblk->status_tag;
sblk->status &= ~SD_STATUS_UPDATED;
-
if (likely(tg3_has_work(tp)))
netif_rx_schedule(dev); /* schedule NAPI poll */
else {
- /* no work, re-enable interrupts
- */
+ /* No work, re-enable interrupts. */
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
- 0x00000000);
+ tp->last_tag << 24);
}
spin_unlock_irqrestore(&tp->lock, flags);
@@ -2969,21 +2978,62 @@ static irqreturn_t tg3_interrupt(int irq
if ((sblk->status & SD_STATUS_UPDATED) ||
!(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) {
/*
- * writing any value to intr-mbox-0 clears PCI INTA# and
+ * Writing any value to intr-mbox-0 clears PCI INTA# and
* chip-internal interrupt pending events.
- * writing non-zero to intr-mbox-0 additional tells the
+ * Writing non-zero to intr-mbox-0 additional tells the
* NIC to stop sending us irqs, engaging "in-intr-handler"
* event coalescing.
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
0x00000001);
+ sblk->status &= ~SD_STATUS_UPDATED;
+ if (likely(tg3_has_work(tp)))
+ netif_rx_schedule(dev); /* schedule NAPI poll */
+ else {
+ /* No work, shared interrupt perhaps? re-enable
+ * interrupts, and flush that PCI write
+ */
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ 0x00000000);
+ tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ }
+ } else { /* shared interrupt */
+ handled = 0;
+ }
+
+ spin_unlock_irqrestore(&tp->lock, flags);
+
+ return IRQ_RETVAL(handled);
+}
+
+static irqreturn_t tg3_interrupt_tagged(int irq, void *dev_id, struct pt_regs *regs)
+{
+ struct net_device *dev = dev_id;
+ struct tg3 *tp = netdev_priv(dev);
+ struct tg3_hw_status *sblk = tp->hw_status;
+ unsigned long flags;
+ unsigned int handled = 1;
+
+ spin_lock_irqsave(&tp->lock, flags);
+
+ /* In INTx mode, it is possible for the interrupt to arrive at
+ * the CPU before the status block posted prior to the interrupt.
+ * Reading the PCI State register will confirm whether the
+ * interrupt is ours and will flush the status block.
+ */
+ if ((sblk->status & SD_STATUS_UPDATED) ||
+ !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) {
/*
- * Flush PCI write. This also guarantees that our
- * status block has been flushed to host memory.
+ * writing any value to intr-mbox-0 clears PCI INTA# and
+ * chip-internal interrupt pending events.
+ * writing non-zero to intr-mbox-0 additional tells the
+ * NIC to stop sending us irqs, engaging "in-intr-handler"
+ * event coalescing.
*/
- tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
+ 0x00000001);
+ tp->last_tag = sblk->status_tag;
sblk->status &= ~SD_STATUS_UPDATED;
-
if (likely(tg3_has_work(tp)))
netif_rx_schedule(dev); /* schedule NAPI poll */
else {
@@ -2991,7 +3041,7 @@ static irqreturn_t tg3_interrupt(int irq
* interrupts, and flush that PCI write
*/
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW,
- 0x00000000);
+ tp->last_tag << 24);
tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
}
} else { /* shared interrupt */
@@ -5445,7 +5495,8 @@ static int tg3_reset_hw(struct tg3 *tp)
udelay(100);
tw32_mailbox(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0);
- tr32(MAILBOX_INTERRUPT_0);
+ tr32(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW);
+ tp->last_tag = 0;
if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS)) {
tw32_f(DMAC_MODE, DMAC_MODE_ENABLE);
@@ -5723,31 +5774,33 @@ static void tg3_timer(unsigned long __op
spin_lock_irqsave(&tp->lock, flags);
spin_lock(&tp->tx_lock);
- /* All of this garbage is because when using non-tagged
- * IRQ status the mailbox/status_block protocol the chip
- * uses with the cpu is race prone.
- */
- if (tp->hw_status->status & SD_STATUS_UPDATED) {
- tw32(GRC_LOCAL_CTRL,
- tp->grc_local_ctrl | GRC_LCLCTRL_SETINT);
- } else {
- tw32(HOSTCC_MODE, tp->coalesce_mode |
- (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
- }
+ if (!(tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)) {
+ /* All of this garbage is because when using non-tagged
+ * IRQ status the mailbox/status_block protocol the chip
+ * uses with the cpu is race prone.
+ */
+ if (tp->hw_status->status & SD_STATUS_UPDATED) {
+ tw32(GRC_LOCAL_CTRL,
+ tp->grc_local_ctrl | GRC_LCLCTRL_SETINT);
+ } else {
+ tw32(HOSTCC_MODE, tp->coalesce_mode |
+ (HOSTCC_MODE_ENABLE | HOSTCC_MODE_NOW));
+ }
- if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) {
- tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER;
- spin_unlock(&tp->tx_lock);
- spin_unlock_irqrestore(&tp->lock, flags);
- schedule_work(&tp->reset_task);
- return;
+ if (!(tr32(WDMAC_MODE) & WDMAC_MODE_ENABLE)) {
+ tp->tg3_flags2 |= TG3_FLG2_RESTART_TIMER;
+ spin_unlock(&tp->tx_lock);
+ spin_unlock_irqrestore(&tp->lock, flags);
+ schedule_work(&tp->reset_task);
+ return;
+ }
}
- if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
- tg3_periodic_fetch_stats(tp);
-
/* This part only runs once per second. */
if (!--tp->timer_counter) {
+ if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
+ tg3_periodic_fetch_stats(tp);
+
if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) {
u32 mac_stat;
int phy_event;
@@ -5846,9 +5899,13 @@ static int tg3_test_interrupt(struct tg3
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI)
err = request_irq(tp->pdev->irq, tg3_msi,
SA_SAMPLE_RANDOM, dev->name, dev);
- else
- err = request_irq(tp->pdev->irq, tg3_interrupt,
+ else {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+ err = request_irq(tp->pdev->irq, fn,
SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err)
return err;
@@ -5900,9 +5957,14 @@ static int tg3_test_msi(struct tg3 *tp)
tp->tg3_flags2 &= ~TG3_FLG2_USING_MSI;
- err = request_irq(tp->pdev->irq, tg3_interrupt,
- SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+ err = request_irq(tp->pdev->irq, fn,
+ SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err)
return err;
@@ -5959,9 +6021,14 @@ static int tg3_open(struct net_device *d
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI)
err = request_irq(tp->pdev->irq, tg3_msi,
SA_SAMPLE_RANDOM, dev->name, dev);
- else
- err = request_irq(tp->pdev->irq, tg3_interrupt,
+ else {
+ irqreturn_t (*fn)(int, void *, struct pt_regs *)=tg3_interrupt;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ fn = tg3_interrupt_tagged;
+
+ err = request_irq(tp->pdev->irq, fn,
SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+ }
if (err) {
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
@@ -5980,9 +6047,16 @@ static int tg3_open(struct net_device *d
tg3_halt(tp, 1);
tg3_free_rings(tp);
} else {
- tp->timer_offset = HZ / 10;
- tp->timer_counter = tp->timer_multiplier = 10;
- tp->asf_counter = tp->asf_multiplier = (10 * 120);
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
+ tp->timer_offset = HZ;
+ else
+ tp->timer_offset = HZ / 10;
+
+ BUG_ON(tp->timer_offset > HZ);
+ tp->timer_counter = tp->timer_multiplier =
+ (HZ / tp->timer_offset);
+ tp->asf_counter = tp->asf_multiplier =
+ ((HZ / tp->timer_offset) * 120);
init_timer(&tp->timer);
tp->timer.expires = jiffies + tp->timer_offset;
@@ -6005,6 +6079,16 @@ static int tg3_open(struct net_device *d
if (tp->tg3_flags2 & TG3_FLG2_USING_MSI) {
err = tg3_test_msi(tp);
+
+ /* All MSI supporting chips should support tagged
+ * status. Assert that this is the case.
+ */
+ if (!(tp->tg3_flags2 & TG3_FLAG_TAGGED_STATUS)) {
+ printk(KERN_WARNING PFX "%s: MSI without TAGGED? "
+ "Not using MSI.\n", tp->dev->name);
+ err = -EINVAL;
+ }
+
if (err) {
spin_lock_irq(&tp->lock);
spin_lock(&tp->tx_lock);
@@ -8422,15 +8506,7 @@ static int __devinit tg3_get_invariants(
if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
tp->tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
- /* Only 5701 and later support tagged irq status mode.
- * Also, 5788 chips cannot use tagged irq status.
- *
- * However, since we are using NAPI avoid tagged irq status
- * because the interrupt condition is more difficult to
- * fully clear in that mode.
- */
tp->coalesce_mode = 0;
-
if (GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_AX &&
GET_CHIP_REV(tp->pci_chip_rev_id) != CHIPREV_5700_BX)
tp->coalesce_mode |= HOSTCC_MODE_32BYTE;
@@ -8494,6 +8570,18 @@ static int __devinit tg3_get_invariants(
grc_misc_cfg == GRC_MISC_CFG_BOARD_ID_5788M))
tp->tg3_flags2 |= TG3_FLG2_IS_5788;
+ if (!(tp->tg3_flags2 & TG3_FLG2_IS_5788) &&
+ (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700))
+ tp->tg3_flags |= TG3_FLAG_TAGGED_STATUS;
+ if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS) {
+ tp->coalesce_mode |= (HOSTCC_MODE_CLRTICK_RXBD |
+ HOSTCC_MODE_CLRTICK_TXBD);
+
+ tp->misc_host_ctrl |= MISC_HOST_CTRL_TAGGED_STATUS;
+ pci_write_config_dword(tp->pdev, TG3PCI_MISC_HOST_CTRL,
+ tp->misc_host_ctrl);
+ }
+
/* these are limited to 10/100 only */
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 &&
(grc_misc_cfg == 0x8000 || grc_misc_cfg == 0x4000)) ||
--- 1/drivers/net/tg3.h.~1~ 2005-05-05 17:15:59.000000000 -0700
+++ 2/drivers/net/tg3.h 2005-05-05 20:58:56.000000000 -0700
@@ -2023,6 +2023,7 @@ struct tg3 {
struct tg3_hw_status *hw_status;
dma_addr_t status_mapping;
+ u32 last_tag;
u32 msg_enable;
@@ -2068,6 +2069,7 @@ struct tg3 {
u32 rx_offset;
u32 tg3_flags;
+#define TG3_FLAG_TAGGED_STATUS 0x00000001
#define TG3_FLAG_TXD_MBOX_HWBUG 0x00000002
#define TG3_FLAG_RX_CHECKSUMS 0x00000004
#define TG3_FLAG_USE_LINKCHG_REG 0x00000008
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: jamal @ 2005-05-09 13:10 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <427F4D50.4060702@trash.net>
On Mon, 2005-09-05 at 13:45 +0200, Patrick McHardy wrote:
> Not sure why they're not marked as per-socket. Probably because
> sadb_x_policy_id is a KAME extension and KAME pf_key doesn't dump
> these policies with SADB_X_SPDDUMP. Racoon needs to skip them
> to avoid adding them to its internal SPD, they could conflict
> with global policies.
>
But as you can see without having some KAME extension or explicit flag
it resorts to some hack. I have a feeling they may have to put a
different hack for each OS that is not BSD derived.
> >>So how could we handle this?
> >>
> > We can disallow the explicit setting of any index which passes test
> > (index % 8 >= 3) - but it does seem to me the whole concept of reserving
> > those indices for per-socket policies is a bit of a hack and may need a
> > rethinking. Maybe we need to maintain a mark in the kernel for
> > per-socket polices and do the same as BSD?
>
> Disallowing this special case seems a bit inconsistent to me.
Well, those indices are "reserved" in a sense; so if we can get rid of
that speacial casing even better.
> We can
> deduce which are per-socket from the list they are contained in. We
> don't notify on per-socket policy change, perhaps we should also skip
> them when dumping in pf_key.
this sounds reasonable and would remove the necessity of special-casing
those indices.
cheers,
jamal
^ permalink raw reply
* PROBLEM: INET TCP socket communication through loopback
From: Hans Henrik Happe @ 2005-05-09 13:07 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
I have experienced some odd behavior when communicating between multiple
processes through the loopback device using poll() to wait for input.
Attachment 'random-inet.c' is a program that shows the problem. Basically it
starts a number of processes. Each process makes a connection to the each of
the other processes (resembling MPI implementations such as lam-mpi). Now a
given number of messages are sent to a pseudo-random destination. When a
process receives one of the messages it forwards it to another randomly
chosen destination. The program is run as follows:
./random-inet <# processes> <# messages>
Problem: One would expect that this program would use up all the available
CPU-time, but this is not the case. Allready with 3 processes and 1 message
there is still some idle CPU-time and it becomes worse when more process are
added.
As a sanity check i created the same program using UNIX socket created by
socketpair() (random-spair.c). This makes the problem go away.
I have also attached the MPI program 'random-mpi.c' showing the same problem
with lam-mpi 7.0.6.
Another MPI program that does NOT have the problem is 'ring-mpi.c'. This
sends the messages around in a ring of processes. The controlled
communication pattern somehow makes the problem go away.
I have attached the 'ver-linux' of the systems that I have tested. I know
these are not mainline kernels but I have not found any mention of such a
problem in the latest changelogs. I will gladly try it on the mainline if
that would help.
I'm not on the list so please CC.
Hans Henrik Happe
[-- Attachment #2: random-inet.c --]
[-- Type: text/x-csrc, Size: 3941 bytes --]
/*
* usage: random-inet <# processes> <# messages>
*/
#include <stdio.h>
#include <poll.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <fcntl.h>
#include <netdb.h>
int do_connect(int port) {
int n, sock, on=1;
struct addrinfo hints, *res;
char str[6];
void *adr;
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
sprintf(str, "%d", port);
n = getaddrinfo("localhost", str, &hints, &res);
if (n != 0) {
fprintf(stderr,
"getaddrinfo error: [%s]\n",
gai_strerror(n));
return -1;
}
sock = socket(AF_INET, SOCK_STREAM, 0);
if (sock == -1) {
perror("socket");
return -1;
}
if (setsockopt(sock, SOL_TCP, TCP_NODELAY, &on, sizeof(on)) == -1) {
perror("setsockopt");
return -1;
}
if (connect(sock, (struct sockaddr *)res->ai_addr, sizeof(*res->ai_addr)) == -1) {
perror("connect");
return -1;
}
freeaddrinfo(res);
return sock;
}
int start_listen(int port) {
int n, on=1;
int sock;
struct sockaddr_in name;
sock = socket(AF_INET, SOCK_STREAM, 0);
if (sock == -1) {
perror("socket");
return -1;
}
if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) == -1) {
perror("setsockopt");
return -1;
}
name.sin_family = AF_INET;
name.sin_port = htons (port);
name.sin_addr.s_addr = htonl (INADDR_ANY);
if (bind (sock, (struct sockaddr *) &name, sizeof (name)) == -1) {
perror("bind");
return -1;
}
if (listen(sock, 10) == -1) {
perror("listen");
return -1;
}
return sock;
}
int do_accept(int lsock) {
struct sockaddr addr;
socklen_t len = sizeof(addr);
int sock, on=1;
if ((sock = accept(lsock, &addr, &len)) == -1) {
perror("accept");
return -1;
}
if (setsockopt(sock, SOL_TCP, TCP_NODELAY, &on, sizeof(on)) == -1) {
perror("setsockopt");
return -1;
}
return sock;
}
int main(int argc, char *argv[]) {
int i, j, n, cnt, pid, rank, dest;
int lsock;
char data = 'h';
int port = 11100;
/* # processes */
cnt = atoi(argv[1]);
/* # messages */
n = atoi(argv[2]);
{
int socks[cnt-1];
struct pollfd pfds[cnt-1];
/* Create processes */
rank = 0;
for (i=1; i<cnt; i++) {
pid = fork();
if (pid == 0) {
rank=cnt-i;
break;
}
}
/* Setup connections */
lsock = start_listen(port+rank);
for (i=0; i<rank; i++) {
socks[i] = do_accept(lsock);
pfds[i].fd = socks[i];
pfds[i].events = POLLIN;
}
for (i=rank; i<cnt-1; i++) {
socks[i] = do_connect(port+i+1);
pfds[i].fd = socks[i];
pfds[i].events = POLLIN;
}
srandom(rank);
/* Write startup messages */
if (rank < n) {
dest = random()%(cnt-1);
write(socks[dest], &data, 1);
}
/* Receive and forward messages to random destinations */
while (1) {
poll(pfds, cnt-1, -1);
j = 0;
for (i=0; i<cnt-1; i++) {
if (pfds[i].revents != 0) {
read(pfds[i].fd, &data, 1);
j++;
}
}
for (i=0; i<j; i++) {
dest = random()%(cnt-1);
write(socks[dest], &data, 1);
}
}
}
return 0;
}
[-- Attachment #3: ver_linux.2.4.24 --]
[-- Type: text/plain, Size: 1018 bytes --]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux n24 2.4.24 #2 Mon Jan 26 15:59:45 CET 2004 i686 GNU/Linux
Gnu C 3.3.3
Gnu make 3.80
binutils 2.14.90.0.6
util-linux 2.12
mount 2.11x
module-init-tools 0.9.15-pre2
e2fsprogs 1.35-WIP
jfsutils 1.1.2
reiserfsprogs 3.6.11
reiser4progs line
xfsprogs 2.5.11
pcmcia-cs 3.2.5
PPP 2.4.2b3
nfs-utils 1.0.5
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.1.12
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0
Modules Loaded e1000 ehci-hcd pcmcia_core nls_iso8859-1 ntfs msdos reiserfs ext3 jbd agpgart autofs4 i810_audio ac97_codec soundcore i810_rng serial usb-uhci usbcore rtc e100 crc32 nfs lockd sunrpc af_packet
[-- Attachment #4: ver_linux.2.6.11-gentoo-r6 --]
[-- Type: text/plain, Size: 1137 bytes --]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux haptop 2.6.11-gentoo-r6 #7 Sat May 7 18:07:07 CEST 2005 i686 Mobile Intel(R) Celeron(R) CPU 1.60GHz GenuineIntel GNU/Linux
Gnu C 3.3.5-20050130
Gnu make 3.80
binutils 2.15.92.0.2
util-linux 2.12i
mount 2.12i
module-init-tools 3.0
e2fsprogs 1.35
reiserfsprogs 3.6.19
reiser4progs line
PPP 2.4.2
Linux C Library 2.3.4
Dynamic linker (ldd) 2.3.4
Procps 3.2.4
Net-tools 1.60
Kbd 1.12
Sh-utils 5.2.1
udev 045
Modules Loaded usb_storage radeon ohci_hcd e100 orinoco_pci orinoco hermes yenta_socket rsrc_nonstatic pcmcia_core radeonfb i2c_algo_bit snd_intel8x0m i2c_i801 i2c_core snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd intel_agp rtc
[-- Attachment #5: ver_linux.2.6.3-7mdk --]
[-- Type: text/plain, Size: 1158 bytes --]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux mimi.imada.sdu.dk 2.6.3-7mdk #1 Wed Mar 17 15:56:42 CET 2004 i686 Intel(R) Celeron(R) CPU 2.40GHz unknown GNU/Linux
Gnu C 3.4.1
Gnu make 3.80
binutils 2.15.90.0.3
util-linux 2.12a
mount 2.12a
module-init-tools 3.0
e2fsprogs 1.35
reiserfsprogs line
reiser4progs line
nfs-utils 1.0.6
Linux C Library 2.3.3
Dynamic linker (ldd) 2.3.3
Procps 3.2.3
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
Modules Loaded nls_iso8859-1 nls_cp850 vfat fat usb-storage ircomm-tty ircomm irda floppy raw sg st sr_mod sd_mod scsi_mod snd-seq-oss snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-intel8x0 snd-ac97-codec snd-pcm snd-timer gameport snd-page-alloc snd-mpu401-uart snd-rawmidi snd-seq-device snd soundcore md5 ipv6 af_packet 8139too mii ide-cd cdrom loop intel-agp agpgart ehci-hcd uhci-hcd usbcore rtc ext3 jbd
[-- Attachment #6: random-mpi.c --]
[-- Type: text/x-csrc, Size: 908 bytes --]
#include <stdio.h>
#include <mpi.h>
/*
* Sends 'n' messages between processes. When a process
* receives a message it chooses a new destination at random.
*
* usage: random-mpi <n>
*/
main(int argc, char **argv)
{
int n, i, data[1];
int dest, size, rank;
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD,&size);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
n = atoi(argv[1]);
srandom(rank);
/* Send 'n' startup messages. */
if (rank < n) {
while ((dest = (random()%size)) == rank);
MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD);
}
while (1) {
MPI_Recv(data, 1, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
/* Don't send to self. */
while ((dest = (random()%size)) == rank);
MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD);
}
MPI_Finalize();
}
[-- Attachment #7: random-spair.c --]
[-- Type: text/x-csrc, Size: 2310 bytes --]
/*
* usage: random-spair <# processes> <# messages>
*/
#include <stdio.h>
#include <poll.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <fcntl.h>
#include <netdb.h>
int main(int argc, char *argv[]) {
int i, j, n, cnt, pid, rank, dest;
int lsock;
char data;
int port = 11100;
cnt = atoi(argv[1]);
n = atoi(argv[2]);
{
int socks[cnt-1];
struct pollfd pfds[cnt-1];
int spairs[2*cnt*cnt];
for (i=0; i<2*cnt*cnt; i+=2) {
socketpair(AF_UNIX, SOCK_STREAM, 0, spairs+i);
}
/* Create processes */
rank = 0;
for (i=1; i<cnt; i++) {
pid = fork();
if (pid == 0) {
rank=cnt-i;
break;
}
}
/* Assign sockets */
j=0;
for (i=0; i<cnt; i++) {
if (i != rank) {
if (i < rank) {
socks[j] = spairs[2*(i*cnt+rank)];
} else {
socks[j] = spairs[2*(rank*cnt+i)+1];
}
pfds[j].fd = socks[j];
pfds[j].events = POLLIN;
j++;
}
}
srandom(rank);
/* Write startup messages */
if (rank < n) {
dest = random()%(cnt-1);
if (write(socks[dest], &data, 1) == -1) {
perror("write 1");
}
}
/* Receive and forward messages to random destinations */
while (1) {
poll(pfds, cnt-1, -1);
j = 0;
for (i=0; i<cnt-1; i++) {
if (pfds[i].revents != 0) {
if (read(pfds[i].fd, &data, 1) == -1) {
perror("read");
}
j++;
}
}
for (i=0; i<j; i++) {
dest = random()%(cnt-1);
if (write(socks[dest], &data, 1) == -1) {
perror("write 2");
}
}
}
}
return 0;
}
[-- Attachment #8: ring-mpi.c --]
[-- Type: text/x-csrc, Size: 712 bytes --]
#include <stdio.h>
#include <mpi.h>
/*
* Sends 'n' messages in a ring of processes.
*
* usage: ring-mpi <n>
*/
main(int argc, char **argv)
{
int n, i, data[1];
int size, rank, dest;
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD,&size);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
n = atoi(argv[1]);
dest = (rank+1)%size;
/* Send 'n' startup messages. */
if (rank%(size/n) == 0) {
MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD);
}
while (1) {
MPI_Recv(data, 1, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
MPI_Send(data, 1, MPI_INT, dest, 0, MPI_COMM_WORLD);
}
MPI_Finalize();
}
^ permalink raw reply
* forcing a packet to go through hw net device
From: 'Jeff' R. Steinhagen @ 2005-05-09 12:58 UTC (permalink / raw)
To: netdev
Hi!
I have a (maybe trivial) question about the kernel's networking code:
A packet with an "outside" destination goes through all layers including the
hardware interface (user->socket->protocol->IP->HW). However if the packet is
addressed to a local IP the transport through and checks by the hardware
layer are avoided. This is perfectly OK for "normal" network usage.
I am profiling some network hardware and related code. Is it possible to force
an internally generated packet to be send through all/the hardware layers?
Thanks for your help!
Cheers,
Jeff
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: Patrick McHardy @ 2005-05-09 11:45 UTC (permalink / raw)
To: hadi; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <1115573038.19561.174.camel@localhost.localdomain>
jamal wrote:
> I can see where the %8 >= 3 comes from.
> [per socket creation with calls xfrm_gen_index(XFRM_POLICY_MAX+dir)
> and the kernel does things in increments of 8]
>
> I didnt quiet understand that check in racoon: Why this guess work? if
> per-socket policies need to be identified, why dont they get explicitly
> marked as per-socket somehow? I am actually curious why that check is
> needed. Sorry have never stared at the racoon code. Do other IKE/ISAKMP
> daemons depend on it?
Not sure why they're not marked as per-socket. Probably because
sadb_x_policy_id is a KAME extension and KAME pf_key doesn't dump
these policies with SADB_X_SPDDUMP. Racoon needs to skip them
to avoid adding them to its internal SPD, they could conflict
with global policies.
>>So how could we handle this?
>>
> We can disallow the explicit setting of any index which passes test
> (index % 8 >= 3) - but it does seem to me the whole concept of reserving
> those indices for per-socket policies is a bit of a hack and may need a
> rethinking. Maybe we need to maintain a mark in the kernel for
> per-socket polices and do the same as BSD?
Disallowing this special case seems a bit inconsistent to me. We can
deduce which are per-socket from the list they are contained in. We
don't notify on per-socket policy change, perhaps we should also skip
them when dumping in pf_key.
Regards
Patrick
^ permalink raw reply
* SNAT help
From: cranium2003 @ 2005-05-09 8:31 UTC (permalink / raw)
To: net dev
hello,
I want to execute my code at
NF_IP_POST_ROUTING. For that First i want to know
which functions are executing at NF_IP_POST_ROUTING
Hook. Then i have enabled SNAT and I have wrriten code
at NF_IP_POST_ROUTING but i want to get outgoing
packets' IP address as new one SNAT'ed IP address not
the one that is before SNAT? How can i do that?
I observe that my code and SNAT are executing
at same HOOK NF_IP_POST_ROUTING. But my code is
executed first and then SNAT is doen but how to
reverse that?
regards,
cranium
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ permalink raw reply
* Re: [2.6 patch] net/sctp/: make two functions static
From: Sridhar Samudrala @ 2005-05-09 4:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: lksctp-developers, netdev, linux-kernel
In-Reply-To: <20050506222549.GW3590@stusta.de>
Adrian Bunk wrote:
>This patch makes two needlessly global functions static.
>
>Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>
Acked-by: Sridhar Samudrala <sri@us.ibm.com>
>---
>
> include/net/sctp/sm.h | 3 ---
> net/sctp/sm_statefuns.c | 13 +++++++++++--
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
>--- linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h.old 2005-05-05 22:59:54.000000000 +0200
>+++ linux-2.6.12-rc3-mm3-full/include/net/sctp/sm.h 2005-05-06 00:17:40.000000000 +0200
>@@ -130,7 +130,6 @@
> sctp_state_fn_t sctp_sf_ootb;
> sctp_state_fn_t sctp_sf_pdiscard;
> sctp_state_fn_t sctp_sf_violation;
>-sctp_state_fn_t sctp_sf_violation_chunklen;
> sctp_state_fn_t sctp_sf_discard_chunk;
> sctp_state_fn_t sctp_sf_do_5_2_1_siminit;
> sctp_state_fn_t sctp_sf_do_5_2_2_dupinit;
>@@ -258,8 +257,6 @@
> void sctp_chunk_assign_tsn(struct sctp_chunk *);
> void sctp_chunk_assign_ssn(struct sctp_chunk *);
>
>-void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error);
>-
> /* Prototypes for statetable processing. */
>
> int sctp_do_sm(sctp_event_t event_type, sctp_subtype_t subtype,
>--- linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c.old 2005-05-05 23:00:12.000000000 +0200
>+++ linux-2.6.12-rc3-mm3-full/net/sctp/sm_statefuns.c 2005-05-06 00:19:11.000000000 +0200
>@@ -92,6 +92,14 @@
> sctp_cmd_seq_t *commands);
> static struct sctp_sackhdr *sctp_sm_pull_sack(struct sctp_chunk *chunk);
>
>+static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error);
>+
>+static sctp_disposition_t sctp_sf_violation_chunklen(
>+ const struct sctp_endpoint *ep,
>+ const struct sctp_association *asoc,
>+ const sctp_subtype_t type,
>+ void *arg,
>+ sctp_cmd_seq_t *commands);
>
> /* Small helper function that checks if the chunk length
> * is of the appropriate length. The 'required_length' argument
>@@ -2318,7 +2326,7 @@
> *
> * This is common code called by several sctp_sf_*_abort() functions above.
> */
>-void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error)
>+static void sctp_stop_t1_and_abort(sctp_cmd_seq_t *commands, __u16 error)
> {
> sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
> SCTP_STATE(SCTP_STATE_CLOSED));
>@@ -3672,7 +3680,8 @@
> *
> * Generate an ABORT chunk and terminate the association.
> */
>-sctp_disposition_t sctp_sf_violation_chunklen(const struct sctp_endpoint *ep,
>+static sctp_disposition_t sctp_sf_violation_chunklen(
>+ const struct sctp_endpoint *ep,
> const struct sctp_association *asoc,
> const sctp_subtype_t type,
> void *arg,
>
>
>
>
^ permalink raw reply
* Re: [PATCH] fix long-standing bug in 2.6/2.4 skb_copy/skb_copy_expand
From: Herbert Xu @ 2005-05-09 3:04 UTC (permalink / raw)
To: Stuffed Crust; +Cc: davem, linux-kernel, netdev
In-Reply-To: <20050508143259.GA30676@shaftnet.org>
Stuffed Crust <pizza@shaftnet.org> wrote:
>
> This is, fortunately, generally true. But if the alloc_skb function
> allocates extra head room (ie calls skb_reserve() on the skb before it
> passes it to the callee, this doesn't quite work. Instead, it should be
> rewritten as:
As far as I know the alloc_skb funciton in the kernel tree doesn't do
that so your patch is not necessary unless we decide to change the way
alloc_skb works. If that's what you want then please provide a patch
to alloc_skb and a rationale as to why we should do that.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification
From: jamal @ 2005-05-09 0:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Masahide NAKAMURA, Patrick McHardy, netdev
In-Reply-To: <20050508214049.GA14415@gondor.apana.org.au>
On Mon, 2005-09-05 at 07:40 +1000, Herbert Xu wrote:
> On Sun, May 08, 2005 at 09:56:33AM -0400, jamal wrote:
> >
> > Why would someone need to deduce whether it has been deleted by index or
> > selector?
>
> It isn't just about deducing the message. It's about sending a delete
> message in the same format as we would receive them. As it is the
> delete message sent would be not be accepted if you sent it back to the
>
If you enumerate all netlink messages, you will see this is not always
the case. It is a nice but not a necessary condition; infact, not even
what you generate with that patch is _the same_ message that was sent
(you add new TLVs in the response that didnt exist in user->kernel).
What is necessary is that if i look at the event i know exactly what was
deleted. If i have such detail, i can build the message that was sent
from user->kernel to delete the object (because i know exactly what was
deleted).
As an example:
I can derive the xfrm_usersa_id that was sent to the kernel if the event
sent me xfrm_usersa_info and therefore build the same a message that
will delete _exactly_ the same object.
It does get worse on occasion (I can point at tc filters) - where you
really cant derive the deleted object.
> > If yes, how do you distinguish the two cases when you are sending the
> > netlink event?
>
> Using the byid attribute that *you* introduced :)
>
Ok, theres no inconsistency then.
> > It doesnt seem to me what you provided in the patch produces exactly the
> > same thing that was sent by user space back in the event.
>
> That's not the point. The point is if you send exactly the same
> message to the kernel, even with the RTAs attached, the kernel
> would accept it and perform the deletion if there is a matching
> policy.
So you are depending on the kernel not checking for the extra TLVs you
send?;->
Refer to what i said above.
>
> > Heres what i will say so we can put this to rest:
> > The patch is unneeded (i hate to use strong words like bogus - but it is
> > getting close to that), but if you feel strongly about it just lets have
> > it well documented and provide the iproute2 patch as well.
>
> I'll leave the decision up to Dave.
Like i said: I think its extraneous stuff that is unneeded(what is in
there at the moment is sufficient detail) - but because theres no
inconsistency, i will not squirm in pain if it is included. I am
agreeing to disagree essentially ;->
cheers,
jamal
^ permalink raw reply
* Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification
From: Herbert Xu @ 2005-05-08 21:40 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, Masahide NAKAMURA, Patrick McHardy, netdev
In-Reply-To: <1115560594.19561.117.camel@localhost.localdomain>
On Sun, May 08, 2005 at 09:56:33AM -0400, jamal wrote:
>
> Why would someone need to deduce whether it has been deleted by index or
> selector?
It isn't just about deducing the message. It's about sending a delete
message in the same format as we would receive them. As it is the
delete message sent would be not be accepted if you sent it back to the
> Does pfkey have ability to delete by index and selector?
Yes.
> If yes, how do you distinguish the two cases when you are sending the
> netlink event?
Using the byid attribute that *you* introduced :)
> > As it is the netlink delete messages sent by notification are invalid
> > by its own standard.
>
> It doesnt seem to me what you provided in the patch produces exactly the
> same thing that was sent by user space back in the event.
That's not the point. The point is if you send exactly the same
message to the kernel, even with the RTAs attached, the kernel
would accept it and perform the deletion if there is a matching
policy.
> Heres what i will say so we can put this to rest:
> The patch is unneeded (i hate to use strong words like bogus - but it is
> getting close to that), but if you feel strongly about it just lets have
> it well documented and provide the iproute2 patch as well.
I'll leave the decision up to Dave.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: SFQ: Reordering?
From: Thomas Graf @ 2005-05-08 18:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Asim Shankar, netdev
In-Reply-To: <427E3847.3050709@trash.net>
* Patrick McHardy <427E3847.3050709@trash.net> 2005-05-08 18:03
> Actually I was beginning to think you're right about having this
> feature optional. Paul McKenney's paper on SFQ states multiple times
> that perturbation can cause reordering if implemented the easy way,
> the Debian sfq manpage mentions this as well. So it appears to be a
> design-choice. Anyways, I suggest to make the decision when we know
> what the costs are.
>
> BTW, this is the URL for the paper:
> http://rdrop.com/users/paulmck/paper/sfq.2002.06.04.pdf
Indeed, well I think it depends on the perturbation interval,
complexity and cost of the hashing function and the average
queue length so having a flag to toggle this feature is
certainly not a bad idea. Assuming a considerable queue length
and a perturbation level of 1-5 seconds it probably doesn't
make sense to rehash.
> I agree both make sense. Are you talking about run-time adjustable
> or compile-time adjustable? For SNAT it would also be nice to be
> able to use the original address, unfortunately this isn't possible
> anymore since we now drop the conntrack reference early.
We can compute the hash at ingress or just before we drop the
reference, store it in tc_classid and then use it at the egress
sfq. Needs some more thinking but should be doable.
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: jamal @ 2005-05-08 17:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <427E2F0D.4040902@trash.net>
On Sun, 2005-08-05 at 17:23 +0200, Patrick McHardy wrote:
> Allowing the user to freely set indices breaks racoon:
>
> #ifdef __linux__
> /* bsd skips over per-socket policies because there will be no
> * src and dst extensions in spddump messages. On Linux the only
> * way to achieve the same is check for policy id.
> */
> if (xpl->sadb_x_policy_id % 8 >= 3) return 0;
> #endif
>
I can see where the %8 >= 3 comes from.
[per socket creation with calls xfrm_gen_index(XFRM_POLICY_MAX+dir)
and the kernel does things in increments of 8]
I didnt quiet understand that check in racoon: Why this guess work? if
per-socket policies need to be identified, why dont they get explicitly
marked as per-socket somehow? I am actually curious why that check is
needed. Sorry have never stared at the racoon code. Do other IKE/ISAKMP
daemons depend on it?
> So how could we handle this?
>
We can disallow the explicit setting of any index which passes test
(index % 8 >= 3) - but it does seem to me the whole concept of reserving
those indices for per-socket policies is a bit of a hack and may need a
rethinking. Maybe we need to maintain a mark in the kernel for
per-socket polices and do the same as BSD?
cheers,
jamal
^ permalink raw reply
* Re: SFQ: Reordering?
From: Patrick McHardy @ 2005-05-08 16:03 UTC (permalink / raw)
To: Thomas Graf; +Cc: Asim Shankar, netdev
In-Reply-To: <20050508115100.GQ28419@postel.suug.ch>
Thomas Graf wrote:
> * Patrick McHardy <427C19C3.5030304@trash.net> 2005-05-07 03:28
>
>>You stated my goal precisely :) I know many people set the interval
>>to too low values, but because of the tight limits, it shouldn't be
>>very expensive anyways. Table switching OTOH would introduce frequently
>>occuring unfairness, and the time to work through a full table is
>>a lot longer, especially in the environments where SFQ is used.
>
> I think you are right on this so forget about my thought.
Actually I was beginning to think you're right about having this
feature optional. Paul McKenney's paper on SFQ states multiple times
that perturbation can cause reordering if implemented the easy way,
the Debian sfq manpage mentions this as well. So it appears to be a
design-choice. Anyways, I suggest to make the decision when we know
what the costs are.
BTW, this is the URL for the paper:
http://rdrop.com/users/paulmck/paper/sfq.2002.06.04.pdf
> Maybe as
> an additional input it might be worth mentioning that I have patches
> ready to a) make the sfq depth adjustable and b) hash algorithm
> selection to a few builtin ones and additional to read theh hash
> from tc_classid set by an action. A real world example where this
> is useful is for routers primarly doing SNAT without any own local
> traffic where hashing algorithm primarly based on the source port
> makes a lot more sense.
I agree both make sense. Are you talking about run-time adjustable
or compile-time adjustable? For SNAT it would also be nice to be
able to use the original address, unfortunately this isn't possible
anymore since we now drop the conntrack reference early.
Regards
Patrick
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: Patrick McHardy @ 2005-05-08 15:23 UTC (permalink / raw)
To: hadi; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <1115562643.19561.148.camel@localhost.localdomain>
jamal wrote:
> On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote:
>
>>Please elaborate by giving an example of how the index is actually
>>used. Sorry, but as it is I'm too thick to see your point :)
>
> I have given you enough info that i am concluding this is now becoming a
> debate for the sake of one;->
>
> Sorry, Herbert, I strongly disagree with your views on this topic. This
> is one of those moments when it becomes obvious there can be no
> compromise. So I am hoping that someone following this discussion or
> writing management apps would speak up.
Allowing the user to freely set indices breaks racoon:
#ifdef __linux__
/* bsd skips over per-socket policies because there will be no
* src and dst extensions in spddump messages. On Linux the only
* way to achieve the same is check for policy id.
*/
if (xpl->sadb_x_policy_id % 8 >= 3) return 0;
#endif
So how could we handle this?
Regards
Patrick
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: jamal @ 2005-05-08 14:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20050508080730.GA30512@gondor.apana.org.au>
On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote:
> On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote:
> >
> > Rewrite it Herbert ;-> I have no qualms as long as the feature is
> > available. I even promised not to harass you ;->
>
> Sorry, I can't think of any good ways to implement what you want.
>
There is really nothing in my (small) patch that you have pointed out
that is unresolvable;->
You just dont like the idea, period.
> > > The difference is that the uniqueness is easy when we (the kernel) are
> > > the only ones setting it. Once you let the user choose the value for
> > > index, that's where the horror starts.
> >
> > But the uniqueness is still maintained. Nothing changes there.
>
> The difference is that we now have to guarantee the uniqueness of
> two unrelated fields during insertion: the index as well as the
> selector. This is where the complexity of your patch comes from.
Both the index and the selector MUST be unique, no question about that.
What i did is introduce setting of the index - and that makes the
checking do a little more. It would be worng not to do the checking.
> I'm afraid I don't buy this. The policies are not stored in a
> linear random-access data structure. So setting the index
> doesn't help performance one tiny bit.
>
> In future it'll probably become a hash table or a tree, in neither
> case will there be a linear index that could be used to determine
> insertion/deletion.
>
I am talking about user space apps - not the kernel.
Have you ever looked at IPSEC related MIBs and PIBs? or apps that
implement those sorts of entities? I suspect you have not otherwise we
would have closed this ages ago.
> Please elaborate by giving an example of how the index is actually
> used. Sorry, but as it is I'm too thick to see your point :)
>
I have given you enough info that i am concluding this is now becoming a
debate for the sake of one;->
Sorry, Herbert, I strongly disagree with your views on this topic. This
is one of those moments when it becomes obvious there can be no
compromise. So I am hoping that someone following this discussion or
writing management apps would speak up.
> > Having said the above, the SAD as well oughta have an index; infact one
> > exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD,
> > yet ;-> not for the next few months until we talk at netconf probably.
>
> The reqid is definitely not an index. In fact it is not unique at all.
> It's a way of condensing all the fields in a SA template into one u32.
>
I dont wanna talk about this right now;
cheers,
jamal
^ permalink raw reply
* Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification
From: jamal @ 2005-05-08 13:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Masahide NAKAMURA, Patrick McHardy, netdev
In-Reply-To: <20050507193538.GA28991@gondor.apana.org.au>
On Sun, 2005-08-05 at 05:35 +1000, Herbert Xu wrote:
> On Sat, May 07, 2005 at 08:46:44AM -0400, jamal wrote:
> >
> > No, this is not true. Study the tc code.
> > It is nice to be able to return exactly the same detail - user space can
> > then infer what exactly happened. It is nicer to be able to return more
> > detail because user space doesnt have to infer anything.
>
> This patch is making it return more detail, not less! The full
> description of the deleted policy/state is still being returned,
> albeit as RTA payloads.
It's the other extreme of what i thought.
The only thing user space needs to know is what object was deleted.
If you just passed the id, it could be deduced if user space maintained
state; if you pass the object, no such deduction is needed.
> Prior to the change, netlink users do not know whether the original
> policy delete request was by selector or by id. Now that information
> is also returned.
>
Why would someone need to deduce whether it has been deleted by index or
selector?
If you gave me the object - i can reproduce the action of deleting it.
Thats the _only_ important_ thing.
> > You describe the patch this way
> >
> > ---
> > This patch changes the format of the XFRM_MSG_DELSA and
> > XFRM_MSG_DELPOLICY notification so that the main message
> > sent is of the same format as that received by the kernel
> > if the original message was via netlink.
> > ----
> >
> > That it only happens when you delete via netlink. Is this not so?
>
> The same change applies even if you sent the delete via pfkey. What
> the change does is to make netlink always send a delete message that
> is valid in the sense that if you sent it back to netlink then it
> would delete that policy/state.
>
Does pfkey have ability to delete by index and selector?
If yes, how do you distinguish the two cases when you are sending the
netlink event?
> As it is the netlink delete messages sent by notification are invalid
> by its own standard.
>
It doesnt seem to me what you provided in the patch produces exactly the
same thing that was sent by user space back in the event.
You introduce some other new TLVs to reflect it back.
But even that is besides the point:
None of those xfrm objects obey any of the standard rules
netlink uses to begin with - you have more than one way of deleting an
object. What you need to do is the detail of what object was deleted.
Heres what i will say so we can put this to rest:
The patch is unneeded (i hate to use strong words like bogus - but it is
getting close to that), but if you feel strongly about it just lets have
it well documented and provide the iproute2 patch as well.
cheers,
jamal
^ permalink raw reply
* Re: primary and secondary ip addresses
From: Hasso Tepper @ 2005-05-08 12:31 UTC (permalink / raw)
To: Harald Welte
Cc: jamal, Thomas Graf, Henrik Nordstrom, David S. Miller,
Andrea G Forte, nhorman, linux-net, netdev
In-Reply-To: <20050412105442.GV7510@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Mon, Dec 20, 2004 at 08:55:02AM -0500, jamal wrote:
>
> > Didnt boot ;->
> > A small silly magic number i missed. Now boots - but doesnt mean it
> > works. And i dont have much time to spare chasing it.
>
> Due to a customer having again trouble with this issue, I was forced to
> actually spend some time testing it (and merging it to a current
> kernel). At least in my simple tests, it worked like a charm :)
I'm using it for some weeks in production and haven't noticed any issues
either. Would be really good to see it kernel.
regards,
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
^ permalink raw reply
* Re: SFQ: Reordering?
From: Thomas Graf @ 2005-05-08 11:51 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Asim Shankar, netdev
In-Reply-To: <427C19C3.5030304@trash.net>
* Patrick McHardy <427C19C3.5030304@trash.net> 2005-05-07 03:28
> You stated my goal precisely :) I know many people set the interval
> to too low values, but because of the tight limits, it shouldn't be
> very expensive anyways. Table switching OTOH would introduce frequently
> occuring unfairness, and the time to work through a full table is
> a lot longer, especially in the environments where SFQ is used.
I think you are right on this so forget about my thought. Maybe as
an additional input it might be worth mentioning that I have patches
ready to a) make the sfq depth adjustable and b) hash algorithm
selection to a few builtin ones and additional to read theh hash
from tc_classid set by an action. A real world example where this
is useful is for routers primarly doing SNAT without any own local
traffic where hashing algorithm primarly based on the source port
makes a lot more sense.
^ permalink raw reply
* Re: [RFC] textsearch infrastructure + skb_find_text()
From: Thomas Graf @ 2005-05-08 11:45 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, Pablo Neira
In-Reply-To: <1115470985.19561.58.camel@localhost.localdomain>
* Jamal Hadi Salim <1115470985.19561.58.camel@localhost.localdomain> 2005-05-07 09:03
> On Fri, 2005-06-05 at 16:43 +0200, Thomas Graf wrote:
>
> > As you can see, it expects a char * in args[0] and the length of it
> > in args[1]. All it does is check whether all bytes have been read
> > already and if not return the remaining part of the buffer so even
> > if the search algorithm can't consume all the bytes returned it will
> > still work as expected.
> >
>
> Ok, makes sense - in the case of a string spanning multi skbs, i suppose
> it wouldnt matter, correct?
Strings spanning multiple skbs can be handled just like a paged skbs
_iff_ all skbs are known at the point the search starts, otherwise
we'll need more trickering.
> Sorry - I thought you were talking about pre-fetching text as in
> lookahead for text in a regexp state machine.
> I am not sure i see the L1 cache connection. Both seem to have tight for
> loops and depending on the algorithm there would be no difference
> in cache warmth afaics. Infact your scheme may suffer more because it
> has a lot of stuff on the stack. However, playing around with the code
> is the only way to find out.
You're probably right, I suspect mine to perform better because in a
typical search there is less work to do per loop and the interruption
to fetch the next block of text is less intrusive. Time will tell.
^ permalink raw reply
* [PATCH] bug-fix in multipath_drr.c
From: pravin @ 2005-05-08 11:37 UTC (permalink / raw)
To: netdev; +Cc: Einar Lueck, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
hi
This patch fixes a small bug in multipath-drr algorithm registration code.
In function drr_init :: multipath_alg_register(..) is called with
wrong algorithm ID (AFAIU).
Regards,
Pravin.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: multipath_drr-algo-register-fix.patch --]
[-- Type: text/x-patch; name="multipath_drr-algo-register-fix.patch", Size: 607 bytes --]
Signed-off by: Pravin B. Shelar <pravins@calsoftinc.com>
This patch fixes a small bug in multipath_drr algorithm registration code.
Index: linux-2.6.12-rc4/net/ipv4/multipath_drr.c
===================================================================
--- linux-2.6.12-rc4.orig/net/ipv4/multipath_drr.c 2005-05-06 22:20:31.000000000 -0700
+++ linux-2.6.12-rc4/net/ipv4/multipath_drr.c 2005-05-08 03:24:02.000000000 -0700
@@ -244,7 +244,7 @@
if (err)
return err;
- err = multipath_alg_register(&drr_ops, IP_MP_ALG_RR);
+ err = multipath_alg_register(&drr_ops, IP_MP_ALG_DRR);
if (err)
goto fail;
^ permalink raw reply
* Re: resend patch: xfrm policybyid
From: Herbert Xu @ 2005-05-08 8:07 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1115469496.19561.41.camel@localhost.localdomain>
On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote:
>
> Rewrite it Herbert ;-> I have no qualms as long as the feature is
> available. I even promised not to harass you ;->
Sorry, I can't think of any good ways to implement what you want.
> > The difference is that the uniqueness is easy when we (the kernel) are
> > the only ones setting it. Once you let the user choose the value for
> > index, that's where the horror starts.
>
> But the uniqueness is still maintained. Nothing changes there.
The difference is that we now have to guarantee the uniqueness of
two unrelated fields during insertion: the index as well as the
selector. This is where the complexity of your patch comes from.
> As i said in the last email, a lot of known management apps out there
> typically deal with row indices when managing tables: examples include
> SNMP, COPS, etc - and i am not sure how Racoon or pluto store their
> policies but they would be a good fit as well.
> If you can specify what indices get used, then you can do some fast
> lookups when need to (because you specify then based on how things are
> laid out in your current tables). This is the way things are - i am not
> trying to innovate anything here.
> How fast you add or delete these rules is a performance metric that
> affects your setup/teardown rates.
I'm afraid I don't buy this. The policies are not stored in a
linear random-access data structure. So setting the index
doesn't help performance one tiny bit.
In future it'll probably become a hash table or a tree, in neither
case will there be a linear index that could be used to determine
insertion/deletion.
> Theres also another use of being able to use indices: HA
> synchronization in active/backup. If the manager wants to make sure the
> active and backup are exactly the same and it(the manager) maintains
> less amount of data it will ensure that both nodes have exactly the same
> indices as well for the same policy.
Please elaborate by giving an example of how the index is actually
used. Sorry, but as it is I'm too thick to see your point :)
> Having said the above, the SAD as well oughta have an index; infact one
> exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD,
> yet ;-> not for the next few months until we talk at netconf probably.
The reqid is definitely not an index. In fact it is not unique at all.
It's a way of condensing all the fields in a SA template into one u32.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Barn Mate - New Horse Forums
From: Barn Mate @ 2005-05-07 20:48 UTC (permalink / raw)
To: netdev@oss.sgi.com
I just wanted to introduce a new free Horse forum that we are hoping will become a useful resource for everyone. This forum has been online for a short time and is quickly becoming a favorite among horse people around the world.
Please stop by and check out what is going on. We have just added a new Horse Knowledge Base which will provide article, tips, and link lists.
The forum will contain a place to ask questions about horses, barn management, the business side of things, web related things, barn / farm equipment, and much more. We have currently have created over 25 forums. We are also hoping to have regular professionals in the horse industry to assist you with your questions - this is why we need to get things rolling.
The Forums:
http://www.barnmate.com
Register at:
http://www.barnmate.com/forum/policy.asp
(if you have problems registering email me and I can set you up)
If you have any questions or suggestions then please feel free to email me at info@barnmate.com .
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
We are also looking for advertisers. Your advertisement can
be seen by 7,500 visitors per month. Information about
advertising available to members on the forum or by email to
non-members (email me for information)..
This is a great place to advertise a horse, horse merchandise,
your horse business, or any horse publications.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris
www.BarnMate.com
^ 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