* [PATCH 11/11] ucc_geth: enable transmit time stamping.
From: Richard Cochran @ 2011-06-19 11:20 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Shlomi Gridish, Li Yang
In-Reply-To: <cover.1308481491.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping.
Compile tested only.
Cc: Shlomi Gridish <gridish@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/ucc_geth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index ef04105..b091108 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3179,6 +3179,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
spin_unlock_irqrestore(&ugeth->lock, flags);
+ skb_tx_timestamp(skb);
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/3] net/fec: add device tree support
From: Greg Ungerer @ 2011-06-19 11:39 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, patches, netdev, devicetree-discuss, Jason Liu,
linux-kernel, David S. Miller
In-Reply-To: <1308410354-21387-3-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On 06/19/2011 01:19 AM, Shawn Guo wrote:
> It adds device tree data parsing support for fec driver.
>
> Signed-off-by: Jason Liu<jason.hui@linaro.org>
> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> Cc: David S. Miller<davem@davemloft.net>
> ---
> Documentation/devicetree/bindings/net/fsl-fec.txt | 14 ++++++++++
> drivers/net/fec.c | 28 +++++++++++++++++++++
> 2 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/fsl-fec.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
> new file mode 100644
> index 0000000..705111d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
> @@ -0,0 +1,14 @@
> +* Freescale Fast Ethernet Controller (FEC)
> +
> +Required properties:
> +- compatible : should be "fsl,<soc>-fec", "fsl,fec"
> +- reg : address and length of the register set for the device
> +- interrupts : should contain fec interrupt
> +
> +Example:
> +
> +fec@83fec000 {
> + compatible = "fsl,imx51-fec", "fsl,fec";
> + reg =<0x83fec000 0x4000>;
> + interrupts =<87>;
> +};
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 885d8ba..ef3d175 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -44,6 +44,8 @@
> #include<linux/platform_device.h>
> #include<linux/phy.h>
> #include<linux/fec.h>
> +#include<linux/of.h>
> +#include<linux/of_device.h>
>
> #include<asm/cacheflush.h>
>
> @@ -78,6 +80,26 @@ static struct platform_device_id fec_devtype[] = {
> { }
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id fec_dt_ids[] = {
> + { .compatible = "fsl,fec", .data =&fec_devtype[0], },
> + {},
> +};
> +
> +static const struct of_device_id *
> +fec_get_of_device_id(struct platform_device *pdev)
> +{
> + return of_match_device(fec_dt_ids,&pdev->dev);
> +}
> +#else
> +#define fec_dt_ids NULL
> +static inline struct of_device_id *
> +fec_get_of_device_id(struct platform_device *pdev)
> +{
> + return NULL;
> +}
> +#endif
> +
> static unsigned char macaddr[ETH_ALEN];
> module_param_array(macaddr, byte, NULL, 0);
> MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> @@ -1363,6 +1385,11 @@ fec_probe(struct platform_device *pdev)
> struct net_device *ndev;
> int i, irq, ret = 0;
> struct resource *r;
> + const struct of_device_id *of_id;
> +
> + of_id = fec_get_of_device_id(pdev);
fec_get_of_device_id() is defined inside of "#ifdef CONFIG_OF". This
use of it will break compilation when this is not defined.
Regards
Greg
> + if (of_id)
> + pdev->id_entry = (struct platform_device_id *) of_id->data;
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!r)
> @@ -1531,6 +1558,7 @@ static struct platform_driver fec_driver = {
> #ifdef CONFIG_PM
> .pm =&fec_pm_ops,
> #endif
> + .of_match_table = fec_dt_ids,
> },
> .id_table = fec_devtype,
> .probe = fec_probe,
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [PATCH 03/11] emaclite: enable transmit and receive time stamping.
From: Eric Dumazet @ 2011-06-19 11:53 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, John Linn
In-Reply-To: <47d1af192e2a51722c2d93b78d9c25de1116e82a.1308481492.git.richard.cochran@omicron.at>
Le dimanche 19 juin 2011 à 13:19 +0200, Richard Cochran a écrit :
> This patch enables software (and phy device) time stamping. Since this
> MAC uses phylib, adding the hooks make hardware time stamping in the phy
> possible.
>
> Compile tested only.
>
> Cc: John Linn <john.linn@xilinx.com>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/net/xilinx_emaclite.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index 372572c..ae029d0 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -647,7 +647,8 @@ static void xemaclite_rx_handler(struct net_device *dev)
> dev->stats.rx_packets++;
> dev->stats.rx_bytes += len;
>
> - netif_rx(skb); /* Send the packet upstream */
> + if (!skb_defer_rx_timestamp(skb))
> + netif_rx(skb); /* Send the packet upstream */
> }
>
> /**
> @@ -1029,15 +1030,19 @@ static int xemaclite_send(struct sk_buff *orig_skb, struct net_device *dev)
> spin_lock_irqsave(&lp->reset_lock, flags);
> if (xemaclite_send_data(lp, (u8 *) new_skb->data, len) != 0) {
> /* If the Emaclite Tx buffer is busy, stop the Tx queue and
> - * defer the skb for transmission at a later point when the
> + * defer the skb for transmission during the ISR, after the
> * current transmission is complete */
> netif_stop_queue(dev);
> lp->deferred_skb = new_skb;
> spin_unlock_irqrestore(&lp->reset_lock, flags);
Since you unlock reset_lock right here, there is no guarantee something
wont eat 'deferred_skb', so you might manipulate a freed skb after this
point.
> + /* Take the time stamp now, since we can't do this in an ISR. */
> + skb_tx_timestamp(new_skb);
> return 0;
> }
> spin_unlock_irqrestore(&lp->reset_lock, flags);
>
> + skb_tx_timestamp(new_skb);
> +
this one is ok.
> dev->stats.tx_bytes += len;
> dev_kfree_skb(new_skb);
>
^ permalink raw reply
* Re: [PATCH 05/11] fec_mpc52xx: enable transmit and receive time stamping.
From: Eric Dumazet @ 2011-06-19 11:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Grant Likely
In-Reply-To: <69af31599bdb8e8af02028ae37b9c84dd1436741.1308481492.git.richard.cochran@omicron.at>
Le dimanche 19 juin 2011 à 13:20 +0200, Richard Cochran a écrit :
> This patch enables software (and phy device) time stamping. Software
> time stamping using the SO_TIMESTAMPING API was tested and found to be
> working on the LITE5200B board.
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/net/fec_mpc52xx.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index 9f81b1a..102bdbc 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -337,6 +337,7 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
> spin_unlock_irqrestore(&priv->lock, flags);
same problem here : You should call skb_tx_timestamp() before the lock
release, or an interrupt might already freed this skb.
> + skb_tx_timestamp(skb);
>
> if (bcom_queue_full(priv->tx_dmatsk)) {
> netif_stop_queue(dev);
> @@ -434,7 +435,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
> length = status & BCOM_FEC_RX_BD_LEN_MASK;
> skb_put(rskb, length - 4); /* length without CRC32 */
> rskb->protocol = eth_type_trans(rskb, dev);
> - netif_rx(rskb);
> + if (!skb_defer_rx_timestamp(skb))
> + netif_rx(rskb);
>
> spin_lock(&priv->lock);
> }
^ permalink raw reply
* Re: [PATCH 06/11] macb: enable transmit time stamping.
From: Eric Dumazet @ 2011-06-19 11:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Nicolas Ferre
In-Reply-To: <ac8adf65aecd78e714a172a30a0b455e3a12dec9.1308481492.git.richard.cochran@omicron.at>
Le dimanche 19 juin 2011 à 13:20 +0200, Richard Cochran a écrit :
> This patch enables software (and phy device) transmit time stamping
> Compile tested only.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/net/macb.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 6c6a028..6944478 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -676,6 +676,8 @@ static int macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> spin_unlock_irqrestore(&bp->lock, flags);
>
> + skb_tx_timestamp(skb);
> +
> return NETDEV_TX_OK;
> }
>
Same problem here, its not safe.
^ permalink raw reply
* Re: [PATCH 07/11] fs_enet: enable transmit time stamping.
From: Eric Dumazet @ 2011-06-19 11:58 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Pantelis Antoniou, Vitaly Bordug
In-Reply-To: <2a8677b99c6b8d0e34bbf0f6d6a44e6c7992636d.1308481492.git.richard.cochran@omicron.at>
Le dimanche 19 juin 2011 à 13:20 +0200, Richard Cochran a écrit :
> This patch enables software (and phy device) transmit time stamping.
> Compile tested only.
>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index 21abb5c..8dcb272 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -701,6 +701,8 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> spin_unlock_irqrestore(&fep->tx_lock, flags);
>
> + skb_tx_timestamp(skb);
> +
> return NETDEV_TX_OK;
> }
>
Well, I'll stop my review here, there is the same problem I guess in all
your patches.
^ permalink raw reply
* Re: [PATCH 2/3] net/fec: add device tree support
From: Arnd Bergmann @ 2011-06-19 12:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Greg Ungerer, Shawn Guo, patches, netdev, devicetree-discuss,
Jason Liu, linux-kernel, David S. Miller
In-Reply-To: <4DFDDFF4.8000305@snapgear.com>
On Sunday 19 June 2011 13:39:32 Greg Ungerer wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id fec_dt_ids[] = {
> > + { .compatible = "fsl,fec", .data =&fec_devtype[0], },
> > + {},
> > +};
> > +
> > +static const struct of_device_id *
> > +fec_get_of_device_id(struct platform_device *pdev)
> > +{
> > + return of_match_device(fec_dt_ids,&pdev->dev);
> > +}
> > +#else
> > +#define fec_dt_ids NULL
> > +static inline struct of_device_id *
> > +fec_get_of_device_id(struct platform_device *pdev)
> > +{
> > + return NULL;
> > +}
> > +#endif
> > +
> > static unsigned char macaddr[ETH_ALEN];
> > module_param_array(macaddr, byte, NULL, 0);
> > MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> > @@ -1363,6 +1385,11 @@ fec_probe(struct platform_device *pdev)
> > struct net_device *ndev;
> > int i, irq, ret = 0;
> > struct resource *r;
> > + const struct of_device_id *of_id;
> > +
> > + of_id = fec_get_of_device_id(pdev);
>
> fec_get_of_device_id() is defined inside of "#ifdef CONFIG_OF". This
> use of it will break compilation when this is not defined.
>
Why? Note the #else path defining an empty function.
Arnd
^ permalink raw reply
* [PATCH 0/7] net: fixup time stamping batch #1
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
As Eric Dumazet helpfully pointed out, the placing the transmit time
stamp hook after giving the skb to hardware races with the completion
ISR, for those drivers which free the buffer in the ISR.
This series fixes up the first batch of time stamping hook patches.
Richard Cochran (7):
net: correct comment on where to place transmit time stamp hook.
fec: fix race in transmit time stamping.
tg3: fix race in transmit time stamping.
r6040: fix race in transmit time stamping.
stmmac: fix race in transmit time stamping.
smsc9420: fix race in transmit time stamping.
davinci_emac: fix race in transmit time stamping.
drivers/net/davinci_emac.c | 3 ++-
drivers/net/fec.c | 4 ++--
drivers/net/r6040.c | 5 +++--
drivers/net/smsc9420.c | 4 ++--
drivers/net/stmmac/stmmac_main.c | 4 ++--
drivers/net/tg3.c | 4 ++--
include/linux/skbuff.h | 3 +--
7 files changed, 14 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH 1/7] net: correct comment on where to place transmit time stamp hook.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
The comment for the skb_tx_timestamp() function suggests calling it just
after a buffer is released to the hardware for transmission. However,
for drivers that free the buffer in an ISR, this produces a race between
the time stamp code and the ISR. This commit changes the comment to advise
placing the call just before handing the buffer over to the hardware.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
include/linux/skbuff.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c0a4f3a..3e54337 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2028,8 +2028,7 @@ static inline void sw_tx_timestamp(struct sk_buff *skb)
* skb_tx_timestamp() - Driver hook for transmit timestamping
*
* Ethernet MAC Drivers should call this function in their hard_xmit()
- * function as soon as possible after giving the sk_buff to the MAC
- * hardware, but before freeing the sk_buff.
+ * function immediately before giving the sk_buff to the MAC hardware.
*
* @skb: A socket buffer.
*/
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/7] tg3: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 743d997..34ea37d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6088,11 +6088,11 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
entry = NEXT_TX(tnapi->tx_prod);
}
+ skb_tx_timestamp(skb);
+
/* Packets are ready, update Tx producer idx local and on card. */
tw32_tx_mbox(tnapi->prodmbox, entry);
- skb_tx_timestamp(skb);
-
tnapi->tx_prod = entry;
if (unlikely(tg3_tx_avail(tnapi) <= (MAX_SKB_FRAGS + 1))) {
netif_tx_stop_queue(txq);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/7] fec: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/fec.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 965fe90..7ae3f28 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -324,10 +324,10 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
fep->cur_tx = bdp;
- spin_unlock_irqrestore(&fep->hw_lock, flags);
-
skb_tx_timestamp(skb);
+ spin_unlock_irqrestore(&fep->hw_lock, flags);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/7] r6040: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/r6040.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 5ee5f8f..00f06e9 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -836,6 +836,9 @@ static netdev_tx_t r6040_start_xmit(struct sk_buff *skb,
descptr->buf = cpu_to_le32(pci_map_single(lp->pdev,
skb->data, skb->len, PCI_DMA_TODEVICE));
descptr->status = DSC_OWNER_MAC;
+
+ skb_tx_timestamp(skb);
+
/* Trigger the MAC to check the TX descriptor */
iowrite16(0x01, ioaddr + MTPR);
lp->tx_insert_ptr = descptr->vndescp;
@@ -846,8 +849,6 @@ static netdev_tx_t r6040_start_xmit(struct sk_buff *skb,
spin_unlock_irqrestore(&lp->lock, flags);
- skb_tx_timestamp(skb);
-
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/7] stmmac: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/stmmac/stmmac_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index 5b85f4c..d4adc80 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1079,10 +1079,10 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
dev->stats.tx_bytes += skb->len;
- priv->hw->dma->enable_dma_transmission(priv->ioaddr);
-
skb_tx_timestamp(skb);
+ priv->hw->dma->enable_dma_transmission(priv->ioaddr);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/7] smsc9420: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/smsc9420.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 2d84f92..ae4d60a 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -1030,12 +1030,12 @@ static netdev_tx_t smsc9420_hard_start_xmit(struct sk_buff *skb,
pd->tx_ring[index].status = TDES0_OWN_;
wmb();
+ skb_tx_timestamp(skb);
+
/* kick the DMA */
smsc9420_reg_write(pd, TX_POLL_DEMAND, 1);
smsc9420_pci_flush_write(pd);
- skb_tx_timestamp(skb);
-
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 7/7] davinci_emac: fix race in transmit time stamping.
From: Richard Cochran @ 2011-06-19 13:31 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/davinci_emac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index f5688ff..55c8245 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1083,6 +1083,8 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
goto fail_tx;
}
+ skb_tx_timestamp(skb);
+
ret_code = cpdma_chan_submit(priv->txchan, skb, skb->data, skb->len,
GFP_KERNEL);
if (unlikely(ret_code != 0)) {
@@ -1090,7 +1092,6 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
dev_err(emac_dev, "DaVinci EMAC: desc submit failed");
goto fail_tx;
}
- skb_tx_timestamp(skb);
return NETDEV_TX_OK;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] proc: Generalize proc inode allocation
From: Serge E. Hallyn @ 2011-06-19 14:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linux Containers, Alexey Dobriyan, netdev, David Lamparter,
linux-kernel, Serge E. Hallyn
In-Reply-To: <m1wrgkavbm.fsf_-_@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
>
> Generalize the proc inode allocation so that it can be
> used without having to having to create a proc_dir_entry.
>
> This will allow namespace file descriptors to remain light
> weight entitities but still have the same inode number
> when the backing namespace is the same.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
>
> Baring problems in review I plan to merge these patches
> via my linux-2.6-nsfd tree.
>
> fs/proc/generic.c | 26 +++++++++++++-------------
> include/linux/proc_fs.h | 10 ++++++++++
> 2 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
> index f1637f1..65416a1 100644
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -350,14 +350,14 @@ static DEFINE_SPINLOCK(proc_inum_lock); /* protects the above */
> * Return an inode number between PROC_DYNAMIC_FIRST and
> * 0xffffffff, or zero on failure.
> */
> -static unsigned int get_inode_number(void)
> +int proc_alloc_inum(unsigned int *inum)
> {
> unsigned int i;
> int error;
>
> retry:
> - if (ida_pre_get(&proc_inum_ida, GFP_KERNEL) == 0)
> - return 0;
> + if (!ida_pre_get(&proc_inum_ida, GFP_KERNEL))
> + return -ENOMEM;
>
> spin_lock(&proc_inum_lock);
> error = ida_get_new(&proc_inum_ida, &i);
> @@ -365,18 +365,19 @@ retry:
> if (error == -EAGAIN)
> goto retry;
> else if (error)
> - return 0;
> + return error;
>
> if (i > UINT_MAX - PROC_DYNAMIC_FIRST) {
> spin_lock(&proc_inum_lock);
> ida_remove(&proc_inum_ida, i);
> spin_unlock(&proc_inum_lock);
> - return 0;
> + return -ENOSPC;
> }
> - return PROC_DYNAMIC_FIRST + i;
> + *inum = PROC_DYNAMIC_FIRST + i;
> + return 0;
> }
>
> -static void release_inode_number(unsigned int inum)
> +void proc_free_inum(unsigned int inum)
> {
> spin_lock(&proc_inum_lock);
> ida_remove(&proc_inum_ida, inum - PROC_DYNAMIC_FIRST);
> @@ -554,13 +555,12 @@ static const struct inode_operations proc_dir_inode_operations = {
>
> static int proc_register(struct proc_dir_entry * dir, struct proc_dir_entry * dp)
> {
> - unsigned int i;
> struct proc_dir_entry *tmp;
> + int ret;
>
> - i = get_inode_number();
> - if (i == 0)
> - return -EAGAIN;
> - dp->low_ino = i;
> + ret = proc_alloc_inum(&dp->low_ino);
> + if (ret)
> + return ret;
>
> if (S_ISDIR(dp->mode)) {
> if (dp->proc_iops == NULL) {
> @@ -766,7 +766,7 @@ EXPORT_SYMBOL(proc_create_data);
>
> static void free_proc_entry(struct proc_dir_entry *de)
> {
> - release_inode_number(de->low_ino);
> + proc_free_inum(de->low_ino);
>
> if (S_ISLNK(de->mode))
> kfree(de->data);
> diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
> index e7576cf..3067b44 100644
> --- a/include/linux/proc_fs.h
> +++ b/include/linux/proc_fs.h
> @@ -175,6 +175,8 @@ extern struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name,
>
> extern struct file *proc_ns_fget(int fd);
>
> +extern int proc_alloc_inum(unsigned int *pino);
> +extern void proc_free_inum(unsigned int inum);
> #else
>
> #define proc_net_fops_create(net, name, mode, fops) ({ (void)(mode), NULL; })
> @@ -229,6 +231,14 @@ static inline struct file *proc_ns_fget(int fd)
> return ERR_PTR(-EINVAL);
> }
>
> +static inline int proc_alloc_inum(unsigned int *inum)
> +{
> + *inum = 1;
> + return 0;
> +}
> +static inline void proc_free_inum(unsigned int inum)
> +{
> +}
> #endif /* CONFIG_PROC_FS */
>
> #if !defined(CONFIG_PROC_KCORE)
> --
> 1.7.5.1.217.g4e3aa
>
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Grant Likely @ 2011-06-19 15:05 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, patches, netdev, devicetree-discuss, Jason Liu,
linux-kernel, Jeremy Kerr, Sascha Hauer, linux-arm-kernel
In-Reply-To: <20110619073000.GA23171@S2100-06.ap.freescale.net>
On Sun, Jun 19, 2011 at 1:30 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Sat, Jun 18, 2011 at 10:19:34AM -0600, Grant Likely wrote:
>> On Sat, Jun 18, 2011 at 11:19:12PM +0800, Shawn Guo wrote:
>> > It adds device tree data parsing support for imx tty/serial driver.
>> >
>> > Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>> > Signed-off-by: Jason Liu <jason.hui@linaro.org>
>> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> > ---
>> > .../bindings/tty/serial/fsl-imx-uart.txt | 21 +++++
>> > drivers/tty/serial/imx.c | 81 +++++++++++++++++---
>> > 2 files changed, 92 insertions(+), 10 deletions(-)
>> > create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>> > new file mode 100644
>> > index 0000000..7648e17
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>> > @@ -0,0 +1,21 @@
>> > +* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART)
>> > +
>> > +Required properties:
>> > +- compatible : should be "fsl,<soc>-uart", "fsl,imx-uart"
>>
>> I'd make this "fsl,<soc>-uart", "fsl,imx51-uart"
>>
>> It's better to anchor these things on real silicon, or a real ip block
>> specification rather than something pseudo-generic. Subsequent chips,
>> like the imx53, should simply claim compatibility with the older
>> fsl,imx51-uart.
>
> It is a real IP block on all imx silicons (except imx23 and imx28
> which are known as former stmp).
>
>>
>> (in essence, "fsl,imx51-uart" becomes the generic string without the
>> downside of having no obvious recourse when new silicon shows up that
>> is an imx part, but isn't compatible with the imx51 uart.
>>
> In this case, should imx1 the ancestor of imx family than imx51
> becomes part of that generic string? Claiming uart of imx1, imx21
> and imx31 (senior than imx51) compatible with the imx51 uart seems
> odd to me.
>
> That said, IMO, "fsl,imx-uart" stands a real IP block specification
> here and can be a perfect generic compatibility string to tell the
> recourse of any imx silicon using this IP.
Yes, but which /version/ of the IP block? Hardware designers are
notorious for changing hardware designs for newer silicon, sometimes
to add features, sometimes to fix bugs. While I understand the
temptation to boil a compatible value down to a nice clean generic
string, doing so only works in a perfect world. In the real world,
you still need to have some information about the specific
implementation. I prefer this specifying it to the SoC name, but I've
been known to be convinced that specifying it to the ip-block name &
version in certain circumstances, like for IP blocks in an FPGA, or
some of the Freescale powerpc pXXXX SoCs which actually had an IP
block swapped out midway through the life of the chip.
Besides, encoding an soc or ip block version into the 'generic'
compatible values is not just good practice, it has *zero downside*.
That's the beauty of the compatible property semantics. Any node can
claim compatibility with an existing device. If no existing device
fits correctly, then the node simple does not claim compatibility.
Drivers can bind to any number of compatible strings, so it would be
just fine for the of_match_table list to include both "fsl,imx-21" and
"fsl,imx-51" (assuming that is the appropriate solution in this case).
>
>> > +- reg : address and length of the register set for the device
>> > +- interrupts : should contain uart interrupt
>> > +- id : should be the port ID defined by soc
>> > +
>> > +Optional properties:
>> > +- fsl,has-rts-cts : indicate it has rts-cts
>> > +- fsl,irda-mode : support irda mode
>> > +
>> > +Example:
>> > +
>> > +uart@73fbc000 {
>> > + compatible = "fsl,imx51-uart", "fsl,imx-uart";
>> > + reg = <0x73fbc000 0x4000>;
>> > + interrupts = <31>;
>> > + id = <1>;
>> > + fsl,has-rts-cts;
>> > +};
>> > diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> > index a544731..2769353 100644
>> > --- a/drivers/tty/serial/imx.c
>> > +++ b/drivers/tty/serial/imx.c
>> > @@ -45,6 +45,8 @@
>> > #include <linux/delay.h>
>> > #include <linux/rational.h>
>> > #include <linux/slab.h>
>> > +#include <linux/of.h>
>> > +#include <linux/of_address.h>
>> >
>> > #include <asm/io.h>
>> > #include <asm/irq.h>
>> > @@ -1223,6 +1225,63 @@ static int serial_imx_resume(struct platform_device *dev)
>> > return 0;
>> > }
>> >
>> > +#ifdef CONFIG_OF
>> > +static int serial_imx_probe_dt(struct imx_port *sport,
>> > + struct platform_device *pdev)
>> > +{
>> > + struct device_node *node = pdev->dev.of_node;
>> > + const __be32 *line;
>> > +
>> > + if (!node)
>> > + return -ENODEV;
>> > +
>> > + line = of_get_property(node, "id", NULL);
>> > + if (!line)
>> > + return -ENODEV;
>> > +
>> > + sport->port.line = be32_to_cpup(line) - 1;
>>
>> Hmmm, I really would like to be rid of this. Instead, if uarts must
>> be enumerated, the driver should look for a /aliases/uart* property
>> that matches the of_node. Doing it that way is already established in
>> the OpenFirmware documentation, and it ensures there are no overlaps
>> in the global namespace.
>>
>
> I just gave one more try to avoid using 'aliases', and you gave a
> 'no' again. Now, I know how hard you are on this. Okay, I start
> thinking about your suggestion seriously :)
Ha ha ha.
>
>> We do need some infrastructure to make that easier though. Would you
>> have time to help put that together?
>>
> Ok, I will give it a try.
Cool. We'll talk next week about it.
^ permalink raw reply
* Re: [PATCH 2/3] net/fec: add device tree support
From: Rob Herring @ 2011-06-19 15:09 UTC (permalink / raw)
To: Arnd Bergmann, Shawn Guo
Cc: linux-arm-kernel, Greg Ungerer, patches, netdev,
devicetree-discuss, Jason Liu, linux-kernel, David S. Miller
In-Reply-To: <201106191411.32137.arnd@arndb.de>
On 06/19/2011 07:11 AM, Arnd Bergmann wrote:
> On Sunday 19 June 2011 13:39:32 Greg Ungerer wrote:
>>> +#ifdef CONFIG_OF
>>> +static const struct of_device_id fec_dt_ids[] = {
>>> + { .compatible = "fsl,fec", .data =&fec_devtype[0], },
>>> + {},
>>> +};
>>> +
>>> +static const struct of_device_id *
>>> +fec_get_of_device_id(struct platform_device *pdev)
>>> +{
>>> + return of_match_device(fec_dt_ids,&pdev->dev);
>>> +}
>>> +#else
>>> +#define fec_dt_ids NULL
>>> +static inline struct of_device_id *
>>> +fec_get_of_device_id(struct platform_device *pdev)
>>> +{
>>> + return NULL;
>>> +}
>>> +#endif
>>> +
>>> static unsigned char macaddr[ETH_ALEN];
>>> module_param_array(macaddr, byte, NULL, 0);
>>> MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
>>> @@ -1363,6 +1385,11 @@ fec_probe(struct platform_device *pdev)
>>> struct net_device *ndev;
>>> int i, irq, ret = 0;
>>> struct resource *r;
>>> + const struct of_device_id *of_id;
>>> +
>>> + of_id = fec_get_of_device_id(pdev);
>>
>> fec_get_of_device_id() is defined inside of "#ifdef CONFIG_OF". This
>> use of it will break compilation when this is not defined.
>>
>
>
> Why? Note the #else path defining an empty function.
>
None of this is necessary in the first place. Just call of_match_device
directly. There is already an empty function to return NULL when
CONFIG_OF is not defined.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Rob Herring @ 2011-06-19 15:15 UTC (permalink / raw)
To: Grant Likely
Cc: Shawn Guo, patches, netdev, devicetree-discuss, Jason Liu,
linux-kernel, Jeremy Kerr, Sascha Hauer, linux-arm-kernel
In-Reply-To: <BANLkTi=1hf7ycwMBcZ0+VDNRMG1_vdnSqA@mail.gmail.com>
On 06/19/2011 10:05 AM, Grant Likely wrote:
> On Sun, Jun 19, 2011 at 1:30 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
>> On Sat, Jun 18, 2011 at 10:19:34AM -0600, Grant Likely wrote:
>>> On Sat, Jun 18, 2011 at 11:19:12PM +0800, Shawn Guo wrote:
>>>> It adds device tree data parsing support for imx tty/serial driver.
>>>>
>>>> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>>>> Signed-off-by: Jason Liu <jason.hui@linaro.org>
>>>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>>>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>>>> ---
>>>> .../bindings/tty/serial/fsl-imx-uart.txt | 21 +++++
>>>> drivers/tty/serial/imx.c | 81 +++++++++++++++++---
>>>> 2 files changed, 92 insertions(+), 10 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>> new file mode 100644
>>>> index 0000000..7648e17
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>> @@ -0,0 +1,21 @@
>>>> +* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART)
>>>> +
>>>> +Required properties:
>>>> +- compatible : should be "fsl,<soc>-uart", "fsl,imx-uart"
>>>
>>> I'd make this "fsl,<soc>-uart", "fsl,imx51-uart"
>>>
>>> It's better to anchor these things on real silicon, or a real ip block
>>> specification rather than something pseudo-generic. Subsequent chips,
>>> like the imx53, should simply claim compatibility with the older
>>> fsl,imx51-uart.
>>
>> It is a real IP block on all imx silicons (except imx23 and imx28
>> which are known as former stmp).
>>
>>>
>>> (in essence, "fsl,imx51-uart" becomes the generic string without the
>>> downside of having no obvious recourse when new silicon shows up that
>>> is an imx part, but isn't compatible with the imx51 uart.
>>>
>> In this case, should imx1 the ancestor of imx family than imx51
>> becomes part of that generic string? Claiming uart of imx1, imx21
>> and imx31 (senior than imx51) compatible with the imx51 uart seems
>> odd to me.
>>
>> That said, IMO, "fsl,imx-uart" stands a real IP block specification
>> here and can be a perfect generic compatibility string to tell the
>> recourse of any imx silicon using this IP.
>
> Yes, but which /version/ of the IP block? Hardware designers are
> notorious for changing hardware designs for newer silicon, sometimes
> to add features, sometimes to fix bugs. While I understand the
> temptation to boil a compatible value down to a nice clean generic
> string, doing so only works in a perfect world. In the real world,
> you still need to have some information about the specific
> implementation. I prefer this specifying it to the SoC name, but I've
> been known to be convinced that specifying it to the ip-block name &
> version in certain circumstances, like for IP blocks in an FPGA, or
> some of the Freescale powerpc pXXXX SoCs which actually had an IP
> block swapped out midway through the life of the chip.
>
There are definitely uart changes along the way with each generation.
> Besides, encoding an soc or ip block version into the 'generic'
> compatible values is not just good practice, it has *zero downside*.
> That's the beauty of the compatible property semantics. Any node can
> claim compatibility with an existing device. If no existing device
> fits correctly, then the node simple does not claim compatibility.
> Drivers can bind to any number of compatible strings, so it would be
> just fine for the of_match_table list to include both "fsl,imx-21" and
> "fsl,imx-51" (assuming that is the appropriate solution in this case).
>
Don't you need uart or serial in here somewhere.
Rob
^ permalink raw reply
* Re: Linux TCP's Robustness to Multipath Packet Reordering
From: Dominik Kaspar @ 2011-06-19 15:22 UTC (permalink / raw)
To: netdev
Cc: Alexander Zimmermann, Yuchung Cheng, Carsten Wolff, John Heffner,
Eric Dumazet, Lennart Schulte, Arnd Hannemann
In-Reply-To: <B35A6FDF-714A-4226-AFF4-D12ECCD4A152@comsys.rwth-aachen.de>
Hello again,
I have another question to Linux TCP and packet reordering. What
exactly happens, when a packet is so much delayed (but not causing a
timeout), that it gets overtaken by a retransmitted version of itself?
It seems to me that this results in "SACK reneging", but I don't
really understand why...
The simplified situation goes this:
- Segment A gets sent and very much delayed (but not causing RTO)
- Segments B, C, D cause dupACKs
- Segment A_ret is retransmitted and ACKed (sent over new path)
- Some more segments E, F, ... are sent and ACKed
- Segment A (the delayed one) arrives at the receiver.
- Now what exactly happens next...?
I use default Linux TCP (with sack=1, dsack=1, fack=1, timestamps=1,
...) and the above described series of events is cause why
transparently forwarding IP packets over multiple paths with RTTs of
10 and 100 milliseconds.
I'd appreciate your help - best regards,
Dominik
^ permalink raw reply
* Re: Linux TCP's Robustness to Multipath Packet Reordering
From: Alexander Zimmermann @ 2011-06-19 15:38 UTC (permalink / raw)
To: Dominik Kaspar
Cc: netdev, Yuchung Cheng, Carsten Wolff, John Heffner, Eric Dumazet,
Lennart Schulte, Arnd Hannemann
In-Reply-To: <BANLkTinueBFkVmR-Hd6d1Yojt+gsAV9PYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
Hi,
Am 19.06.2011 um 17:22 schrieb Dominik Kaspar:
> Hello again,
>
> I have another question to Linux TCP and packet reordering. What
> exactly happens, when a packet is so much delayed (but not causing a
> timeout), that it gets overtaken by a retransmitted version of itself?
> It seems to me that this results in "SACK reneging", but I don't
> really understand why...
in theory, you can detect this case with a combination of DSACK
and timestamps. However, in practice a reordering delay greater than
RTT will likely case an RTO (see RFC4653). IMO, if you have an packet
reordering with an delay greater that the RTT, you have much more problems
that SACK reneging
>
> The simplified situation goes this:
> - Segment A gets sent and very much delayed (but not causing RTO)
> - Segments B, C, D cause dupACKs
> - Segment A_ret is retransmitted and ACKed (sent over new path)
> - Some more segments E, F, ... are sent and ACKed
> - Segment A (the delayed one) arrives at the receiver.
> - Now what exactly happens next...?
Receiver sends a DSACK
>
> I use default Linux TCP (with sack=1, dsack=1, fack=1, timestamps=1,
> ...) and the above described series of events is cause why
> transparently forwarding IP packets over multiple paths with RTTs of
> 10 and 100 milliseconds.
>
> I'd appreciate your help - best regards,
> Dominik
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//
[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 243 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] Series short description
From: Shmulik Ravid @ 2011-06-19 17:58 UTC (permalink / raw)
To: John Fastabend; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20110617211027.26578.11317.stgit@jf-dev1-dcblab>
On Fri, 2011-06-17 at 14:16 -0700, John Fastabend wrote:
> The following series implements improvements to the DCB netlink
> interface. This work was done to improve Application handling
> and support firmware based LLDP agents.
>
> This adds a multicast group for DCB currently user space has
> trouble keeping in sync across multiple applications and with
> firmware agents making DCB attribute changes in the driver.
>
I was working on something along the same lines and would like to add on
top of these changes a notification for the CEE flavor.
^ permalink raw reply
* Re: [PATCH 2/7] net: dcbnl, add multicast group for DCB
From: Shmulik Ravid @ 2011-06-19 18:14 UTC (permalink / raw)
To: John Fastabend; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20110617211618.26578.34100.stgit@jf-dev1-dcblab>
On Fri, 2011-06-17 at 14:16 -0700, John Fastabend wrote:
> Now that dcbnl is being used in many cases by more
> than a single agent it is beneficial to be notified
> when some entity either driver or user space has
> changed the DCB attributes.
>
> Today applications either end up polling the interface
> or relying on a user space database to maintain the DCB
> state and post events. Polling is a poor solution for
> obvious reasons. And relying on a user space database
> has its own downside. Namely it has created strange
> boot dependencies requiring the database be populated
> before any applications dependent on DCB attributes
> starts or the application goes into a polling loop.
> Populating the database requires negotiating link
> setting with the peer and can take anywhere from less
> than a second up to a few seconds depending on the switch
> implementation.
>
> Perhaps more importantly if another application or an
> embedded agent sets a DCB link attribute the database
> has no way of knowing other than polling the kernel.
> This prevents applications from responding quickly to
> changes in link events which at least in the FCoE case
> and probably any other protocols expecting a lossless
> link may result in IO errors.
>
> By adding a multicast group for DCB we have clean way
> to disseminate kernel DCB link attributes up to user
> space. Avoiding the need for user space to maintain
> a coherant database and disperse events that potentially
> do not reflect the current link state.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
> include/linux/rtnetlink.h | 2
> net/dcb/dcbnl.c | 228 +++++++++++++++++++++++++++++----------------
> 2 files changed, 147 insertions(+), 83 deletions(-)
>
[...]
> +static int dcbnl_notify(struct net_device *dev, int event, int cmd,
> + u32 seq, u32 pid)
[...]
A driver supporting an embedded dcbx stack would want to directly invoke
the notification routine, therefore it should be exported. I'd like also
to add support for a CEE notification. Also when the driver invokes the
notification shouldn't it use a new event type something like
RTM_NEWDCB?
^ permalink raw reply
* Re: Linux TCP's Robustness to Multipath Packet Reordering
From: Dominik Kaspar @ 2011-06-19 16:25 UTC (permalink / raw)
To: Alexander Zimmermann
Cc: netdev, Yuchung Cheng, Carsten Wolff, John Heffner, Eric Dumazet,
Lennart Schulte, Arnd Hannemann
In-Reply-To: <C040825C-480A-46C6-AF32-76D90717BA06@comsys.rwth-aachen.de>
Hi Alexander,
Ah... the receiver DSACKs the "original" packet. However, the sender
already received an ACK for its retransmission and advances SND.UNA.
When the DSACK finally arrives, it is actually outside of the SND.UNA
- SND.NXT range, which causes the DSACK to trigger "SACK reneging".
Did I get that right? :-)
Cheers,
Dominik
On Sun, Jun 19, 2011 at 5:38 PM, Alexander Zimmermann
<alexander.zimmermann@comsys.rwth-aachen.de> wrote:
> Hi,
>
> Am 19.06.2011 um 17:22 schrieb Dominik Kaspar:
>
>> Hello again,
>>
>> I have another question to Linux TCP and packet reordering. What
>> exactly happens, when a packet is so much delayed (but not causing a
>> timeout), that it gets overtaken by a retransmitted version of itself?
>> It seems to me that this results in "SACK reneging", but I don't
>> really understand why...
>
> in theory, you can detect this case with a combination of DSACK
> and timestamps. However, in practice a reordering delay greater than
> RTT will likely case an RTO (see RFC4653). IMO, if you have an packet
> reordering with an delay greater that the RTT, you have much more problems
> that SACK reneging
>
>>
>> The simplified situation goes this:
>> - Segment A gets sent and very much delayed (but not causing RTO)
>> - Segments B, C, D cause dupACKs
>> - Segment A_ret is retransmitted and ACKed (sent over new path)
>> - Some more segments E, F, ... are sent and ACKed
>> - Segment A (the delayed one) arrives at the receiver.
>> - Now what exactly happens next...?
>
> Receiver sends a DSACK
>
>>
>> I use default Linux TCP (with sack=1, dsack=1, fack=1, timestamps=1,
>> ...) and the above described series of events is cause why
>> transparently forwarding IP packets over multiple paths with RTTs of
>> 10 and 100 milliseconds.
>>
>> I'd appreciate your help - best regards,
>> Dominik
>
> //
> // Dipl.-Inform. Alexander Zimmermann
> // Department of Computer Science, Informatik 4
> // RWTH Aachen University
> // Ahornstr. 55, 52056 Aachen, Germany
> // phone: (49-241) 80-21422, fax: (49-241) 80-22222
> // email: zimmermann@cs.rwth-aachen.de
> // web: http://www.umic-mesh.net
> //
>
>
^ permalink raw reply
* [PATCH V2 00/11] net: expand time stamping, batch #2
From: Richard Cochran @ 2011-06-19 17:56 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
This patch series represents a continuation of the effort to get
better coverage of the SO_TIMESTAMPING socket API in the Ethernet
drivers. Adding time stamping support to a given driver solves two
separate issues, namely software transmit time stamping and hardware
time stamping in PHY devices.
This second batch adds the hooks into all remaining (?) arm and
powerpc MAC drivers using phylib. The first patch exports the receive
hook for use by non-NAPI drivers when compiled as modules. Patch #5
has been tested on real hardware, but the rest have only been compile
tested.
Richard Cochran (11):
net: export the receive time stamping hook for non-NAPI drivers
lib8390: enable transmit and receive time stamping.
emaclite: enable transmit and receive time stamping.
ll_temac: enable transmit and receive time stamping.
fec_mpc52xx: enable transmit and receive time stamping.
macb: enable transmit time stamping.
fs_enet: enable transmit time stamping.
smsc911x: enable transmit time stamping.
pxa168_eth: enable transmit time stamping.
mv643xx_eth: enable transmit time stamping.
ucc_geth: enable transmit time stamping.
drivers/net/fec_mpc52xx.c | 4 +++-
drivers/net/fs_enet/fs_enet-main.c | 2 ++
drivers/net/lib8390.c | 5 +++--
drivers/net/ll_temac_main.c | 5 ++++-
drivers/net/macb.c | 2 ++
drivers/net/mv643xx_eth.c | 2 ++
drivers/net/pxa168_eth.c | 3 +++
drivers/net/smsc911x.c | 1 +
drivers/net/ucc_geth.c | 2 ++
drivers/net/xilinx_emaclite.c | 9 +++++++--
net/core/timestamping.c | 1 +
11 files changed, 30 insertions(+), 6 deletions(-)
^ 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