* Re: [PATCH] ipv4: devconf: start IPV4_DEVCONF_* from 0
From: Lucian Adrian Grijincu @ 2011-01-13 12:23 UTC (permalink / raw)
To: Lucian Adrian Grijincu, David Miller, netdev, kuznet, pekkas,
jmorris, yoshfuji
In-Reply-To: <20110113100224.GB30432@canuck.infradead.org>
On Thu, Jan 13, 2011 at 12:02 PM, Thomas Graf <tgraf@infradead.org> wrote:
> On Thu, Jan 13, 2011 at 09:50:14AM +0200, Lucian Adrian Grijincu wrote:
>> Yes it works, but there does not seem to be a good reason why to
>> complicate things like this (again the sentinel nature of zero is not
>> used in any place here).
>
> I have no objects to changing this at all but we don't gain much either.
Should I post a new patch in which IFLA_INET_CONF cfgid values start
from 0 also or must the ABI for libnl be kept as-is (counting from 1)?
--
.
..: Lucian
^ permalink raw reply
* Re: [patch v2] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-13 12:32 UTC (permalink / raw)
To: error27, dan.j.rosenberg; +Cc: netdev, kernel-janitors
In-Reply-To: <20110110.160620.133889003.davem@davemloft.net>
On Tuesday 11 January 2011 02:06:20 ext David Miller, you wrote:
> From: Dan Carpenter <error27@gmail.com>
> Date: Mon, 10 Jan 2011 17:06:58 +0300
>
> > Dan Rosenberg pointed out that there were some signed comparison bugs
> > in the phonet protocol.
> >
> > http://marc.info/?l=full-disclosure&m=129424528425330&w=2
> >
> > The problem is that we check for array overflows but "protocol" is
> > signed and we don't check for array underflows. If you have already
> > have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> > could cause an oops by mistake.
> >
> > Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Applied.
Shouldn't this be sent to stable trees?
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH] ipv4: devconf: start IPV4_DEVCONF_* from 0
From: Alexey Kuznetsov @ 2011-01-13 12:51 UTC (permalink / raw)
To: tgraf, netdev
In-Reply-To: <20110113100224.GB30432@canuck.infradead.org>
Hello!
On Thu, Jan 13, 2011 at 05:02:24AM -0500, Thomas Graf wrote:
> The reason I didn't change anything was the same as Dave's reply, I
> thought it must have been done on purpose.
The days, when this was written, 0 was interpreted as end of array by sysctl core.
BTW, -1=CTL_ANY also used to be special, that's why NET_PROTO_CONF_ALL=-2 rather than -1.
So, yes, it was done on purpose. And, yes, this purpose is not a legal purpose now.
Alexey
^ permalink raw reply
* Re: panic in tg3 driver
From: Stephen Clark @ 2011-01-13 13:12 UTC (permalink / raw)
To: Matt Carlson; +Cc: Linux Kernel Network Developers, Michael Chan
In-Reply-To: <20110112030652.GA27164@mcarlson.broadcom.com>
On 01/11/2011 10:06 PM, Matt Carlson wrote:
> lspci -vvv -xxx -s 81:00.0
Further information - I found these messages in /var/log/messages. It looks
like after it switched to INTx mode interrupts for other devices were hosed.
Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt was gener
ated using MSI. Switching to INTx mode. Please report this failure to the PCI ma
intainer and include system chipset information
Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x6 frozen
Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
Jan 12 08:38:50 localhost kernel: ata2.01: cmd
ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
Jan 12 08:38:50 localhost kernel: res
40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for vector (irq -1)
Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something wicked
happened on session 3363
^ permalink raw reply
* Re: [PATCH 00/22] ipvs namespaces v3.3
From: Simon Horman @ 2011-01-13 13:18 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, lvs-devel, netdev, Patrick McHardy,
Julian Anastasov, Hans Schillstrom
In-Reply-To: <4D2EDDD0.8060903@netfilter.org>
On Thu, Jan 13, 2011 at 12:11:12PM +0100, Pablo Neira Ayuso wrote:
> On 13/01/11 02:52, Simon Horman wrote:
> > Hi Pablo,
> >
> > this changest includes the following changes since the v3.2 series
> > which was most recently posted as "[GIT PULL nf-next-2.6] ipvs namespaces".
> >
> > * Remove several hunks that only make whitespace changes
>
> Thanks a lot for doing this.
>
> > * Add Acked-by: Julian Anastasov <ja@ssi.bg>
> > (It was an omission from v3.2)
> > * Fix merge conflicts
> >
> > There are two changes that produce conflicts
> > * In the current net-next-2.6 tree but absent from the current nf-next-2.6 tree
> > there is "workqueue: convert
> > cancel_rearming_delayed_work[queue]() users to cancel_delayed_work_sync()"
> > * And in the current nf-next-2.6 tree but absent from the current
> > net-next-2.6 tree there is "net: use the macros defined for the members
> > of flowi"
>
> nf-*-2.6 are Patrick's trees. My trees are here:
>
> http://1984.lsi.us.es/git/
Thanks, noted.
> > In order to create this series I merged net-next-2.6 into nf-next-2.6.
> > The result is at
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6 ipvs-netns3.3
> >
> > However, I guess that you have already done your own merge and simply
> > pulling the branch above will create a bit of a mess. Please let me know
> > if you have a tree/branch that I should use as a base for a pull request.
>
> I have pulled it, everything was fine. Thanks Simon!
Great!
^ permalink raw reply
* [PATCH v4] netfilter: ipt_CLUSTERIP: remove "no conntrack!"
From: Eric Dumazet @ 2011-01-13 13:38 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Netfilter Development Mailinglist, netdev, Patrick McHardy
In-Reply-To: <4D2EE80B.6010707@netfilter.org>
Le jeudi 13 janvier 2011 à 12:54 +0100, Pablo Neira Ayuso a écrit :
> But printing this does not provide any useful information. The first
> packet that does not belong to the cluster node that has received the
> packet, or the first invalid packet, will trigger this.
>
> Moreover, this confuses users since they can do nothing if they receive
> this message.
>
> Moreover, this target should be supersedes by the cluster match, which
> has been there for quite some time (it's also more flexible).
Now you mentioned it, cluster match is not as flexible right now,
its hashing is on source_ip only.
Many people still use ipt_CLUSTERIP, and probably for couple of years.
This issue was raised several times, we should fix CLUSTERIP for good.
Thanks
[PATCH v4] netfilter: ipt_CLUSTERIP: remove "no conntrack!"
When a packet is meant to be handled by another node of the cluster,
silently drop it instead of flooding kernel log.
Note : INVALID packets are also dropped without notice.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
CC: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 1e26a48..403ca57 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -300,13 +300,8 @@ clusterip_tg(struct sk_buff *skb, const struct xt_action_param *par)
* that the ->target() function isn't called after ->destroy() */
ct = nf_ct_get(skb, &ctinfo);
- if (ct == NULL) {
- pr_info("no conntrack!\n");
- /* FIXME: need to drop invalid ones, since replies
- * to outgoing connections of other nodes will be
- * marked as INVALID */
+ if (ct == NULL)
return NF_DROP;
- }
/* special case: ICMP error handling. conntrack distinguishes between
* error messages (RELATED) and information requests (see below) */
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4] netfilter: ipt_CLUSTERIP: remove "no conntrack!"
From: Jan Engelhardt @ 2011-01-13 14:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Pablo Neira Ayuso, Netfilter Development Mailinglist, netdev,
Patrick McHardy
In-Reply-To: <1294925915.3570.87.camel@edumazet-laptop>
On Thursday 2011-01-13 14:38, Eric Dumazet wrote:
>Le jeudi 13 janvier 2011 à 12:54 +0100, Pablo Neira Ayuso a écrit :
>
>> But printing this does not provide any useful information. The first
>> packet that does not belong to the cluster node that has received the
>> packet, or the first invalid packet, will trigger this.
>>
>> Moreover, this confuses users since they can do nothing if they receive
>> this message.
>>
>> Moreover, this target should be supersedes by the cluster match, which
>> has been there for quite some time (it's also more flexible).
>
>Now you mentioned it, cluster match is not as flexible right now,
>its hashing is on source_ip only.
I think in that case, xt_cluster should be improved rather
than an old module.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Ben Hutchings @ 2011-01-13 14:03 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294919372-1904-1-git-send-email-ratbert.chuang@gmail.com>
On Thu, 2011-01-13 at 19:49 +0800, Po-Yu Chuang wrote:
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII. This driver has been working on some ARM/NDS32 SoC including
> Faraday A320 and Andes AG101.
[...]
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> new file mode 100644
> index 0000000..97d1f8d
> --- /dev/null
> +++ b/drivers/net/ftmac100.c
[...]
> +#include "ftmac100.h"
> +
> +#define USE_NAPI
All new network drivers should use NAPI only, so please remove the
definition of USE_NAPI and change the conditional code to use NAPI
always.
[...]
> + struct napi_struct napi;
> +#endif
> +
> + struct net_device_stats stats;
There is a net_device_stats structure in the net_device structure; you
should normally use that instead of adding another one.
[...]
> +static int ftmac100_reset(struct ftmac100 *priv)
> +{
> + struct device *dev = &priv->netdev->dev;
> + unsigned long flags;
> + int i;
> +
> + /* NOTE: reset clears all registers */
> +
> + spin_lock_irqsave(&priv->hw_lock, flags);
> + iowrite32(FTMAC100_MACCR_SW_RST, priv->base + FTMAC100_OFFSET_MACCR);
> + spin_unlock_irqrestore(&priv->hw_lock, flags);
> +
> + for (i = 0; i < 5; i++) {
> + int maccr;
> +
> + spin_lock_irqsave(&priv->hw_lock, flags);
> + maccr = ioread32(priv->base + FTMAC100_OFFSET_MACCR);
> + spin_unlock_irqrestore(&priv->hw_lock, flags);
> + if (!(maccr & FTMAC100_MACCR_SW_RST)) {
> + /*
> + * FTMAC100_MACCR_SW_RST cleared does not indicate
> + * that hardware reset completed (what the f*ck).
> + * We still need to wait for a while.
> + */
> + usleep_range(500, 1000);
Sleeping here means this must be running in process context. But you
used spin_lock_irqsave() above which implies you're not sure what the
context is. One of these must be wrong.
I wonder whether hw_lock is even needed; you seem to acquire and release
it around each PIO (read or write). This should be unnecessary since
each PIO is atomic.
[...]
> +static int ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> +{
> + struct net_device *netdev = priv->netdev;
> + struct device *dev = &netdev->dev;
> + unsigned long flags;
> + struct ftmac100_rxdes *rxdes;
> + struct sk_buff *skb;
> + int length;
> + int copied = 0;
> + int done = 0;
> +
> + spin_lock_irqsave(&priv->rx_lock, flags);
> + rxdes = ftmac100_rx_locate_first_segment(priv);
> + spin_unlock_irqrestore(&priv->rx_lock, flags);
> + if (!rxdes)
> + return 0;
> +
> + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
> + spin_lock_irqsave(&priv->rx_lock, flags);
> + ftmac100_rx_drop_packet(priv);
> + spin_unlock_irqrestore(&priv->rx_lock, flags);
I think you can also get rid of rx_lock; it's only used in the RX data
path which is already serialised by NAPI.
[...]
> + netif_rx(skb);
> +#endif
> +
> + netdev->last_rx = jiffies;
Don't set last_rx; the networking core takes care of it now.
> + priv->stats.rx_packets++;
> + priv->stats.rx_bytes += skb->len;
This should be done earlier, so that these stats include packets that
are dropped for any reason.
[...]
> +static int ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
> + dma_addr_t map)
> +{
[...]
> + ftmac100_txdma_start_polling(priv);
> + spin_unlock_irqrestore(&priv->hw_lock, flags);
> + netdev->trans_start = jiffies;
Don't set trans_start; the networking core takes care of it now.
[...]
> +static int ftmac100_alloc_buffers(struct ftmac100 *priv)
> +{
> + int i;
> +
> + priv->descs = dma_alloc_coherent(priv->dev,
> + sizeof(struct ftmac100_descs), &priv->descs_dma_addr,
> + GFP_KERNEL | GFP_DMA);
On x86, GFP_DMA means the memory must be within the ISA DMA range
(< 16 MB). I don't know quite what it means on ARM but it may not be
what you want.
[...]
> +/******************************************************************************
> + * interrupt handler
> + *****************************************************************************/
> +static irqreturn_t ftmac100_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *netdev = dev_id;
> + struct device *dev = &netdev->dev;
> + struct ftmac100 *priv = netdev_priv(netdev);
> + unsigned long flags;
> + unsigned int status;
> + unsigned int imr;
> +
> + spin_lock_irqsave(&priv->hw_lock, flags);
> + status = ioread32(priv->base + FTMAC100_OFFSET_ISR);
> + imr = ioread32(priv->base + FTMAC100_OFFSET_IMR);
> + spin_unlock_irqrestore(&priv->hw_lock, flags);
> +
> + status &= imr;
> + if (status & (FTMAC100_INT_RPKT_FINISH | FTMAC100_INT_NORXBUF)) {
> + /*
> + * FTMAC100_INT_RPKT_FINISH:
> + * RX DMA has received packets into RX buffer successfully
> + *
> + * FTMAC100_INT_NORXBUF:
> + * RX buffer unavailable
> + */
> +#ifdef USE_NAPI
> + /* Disable interrupts for polling */
> + ftmac100_disable_rxint(priv);
> +
> + napi_schedule(&priv->napi);
> +#else
> + int rx = 0;
> +
> + while (ftmac100_rx_packet(priv, &rx))
> + ;
> +#endif
> + }
> +
> + if (status & FTMAC100_INT_NORXBUF) {
> + /* RX buffer unavailable */
> + if (printk_ratelimit())
> + dev_info(dev, "INT_NORXBUF\n");
> +
> + priv->stats.rx_over_errors++;
> + }
> +
> + if (status & (FTMAC100_INT_XPKT_OK | FTMAC100_INT_XPKT_LOST)) {
> + /*
> + * FTMAC100_INT_XPKT_OK:
> + * packet transmitted to ethernet successfully
> + *
> + * FTMAC100_INT_XPKT_LOST:
> + * packet transmitted to ethernet lost due to late
> + * collision or excessive collision
> + */
> + ftmac100_tx_complete(priv);
> + }
TX completions should also be handled through NAPI if possible.
[...]
> +static int ftmac100_open(struct net_device *netdev)
> +{
> + struct device *dev = &netdev->dev;
> + struct ftmac100 *priv = netdev_priv(netdev);
> + int err;
> +
> + err = ftmac100_alloc_buffers(priv);
> + if (err) {
> + dev_err(dev, "failed to allocate buffers\n");
> + goto err_alloc;
> + }
> +
> + err = request_irq(priv->irq, ftmac100_interrupt, 0, netdev->name,
> + netdev);
> + if (err) {
> + dev_err(dev, "failed to request irq %d\n", priv->irq);
> + goto err_irq;
> + }
> +
> + priv->rx_pointer = 0;
> + priv->tx_clean_pointer = 0;
> + priv->tx_pointer = 0;
> + spin_lock_init(&priv->hw_lock);
> + spin_lock_init(&priv->rx_lock);
> + spin_lock_init(&priv->tx_lock);
These locks should be initialised in your probe function.
[...]
> +/******************************************************************************
> + * struct platform_driver functions
> + *****************************************************************************/
> +static int ftmac100_remove(struct platform_device *pdev)
> +{
> + struct net_device *netdev;
> + struct ftmac100 *priv;
> +
> + netdev = platform_get_drvdata(pdev);
> + if (netdev == NULL)
> + return 0;
> +
> + platform_set_drvdata(pdev, NULL);
> +
> + priv = netdev_priv(netdev);
> +
> + unregister_netdev(netdev);
[...]
There should be a netif_napi_del() before this.
A general comment: please use netdev_err(), netdev_info() etc. for
logging. This ensures that both the platform device address and the
network device name appears in the log messages.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-01-13 14:22 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294919372-1904-1-git-send-email-ratbert.chuang@gmail.com>
Le jeudi 13 janvier 2011 à 19:49 +0800, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII. This driver has been working on some ARM/NDS32 SoC including
> Faraday A320 and Andes AG101.
>
> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
> ---
> drivers/net/Kconfig | 9 +
> drivers/net/Makefile | 1 +
> drivers/net/ftmac100.c | 1341 ++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/ftmac100.h | 180 +++++++
> 4 files changed, 1531 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/ftmac100.c
> create mode 100644 drivers/net/ftmac100.h
Hi
1) please use netdev_alloc_skb_ip_align() instead of dev_alloc_skb() +
skb_reserve(skb, NET_IP_ALIGN);
2) Dont include a "struct net_device_stats stats" in struct ftmac100,
you can use the one included in struct net_device
(You can then remove ftmac100_get_stats())
3) Dont "netdev->last_rx = jiffies;" : This is not driver job.
Ditto for trans_start
4) You must comment why wmb() is needed in ftmac100_xmit()
5) Why isnt NAPI used too for TX completions ?
BTW, I am not sure we want a define. All new drivers must use NAPI.
6) Use is_valid_ether_addr() instead of is_zero_ether_addr() in
ftmac100_probe()
7) "static struct ethtool_ops ftmac100_ethtool_ops" should be const :
"static const struct ethtool_ops ftmac100_ethtool_ops"
Ditto for :
"static struct net_device_ops ftmac100_netdev_ops"
8) Why an interrupt handler (ftmac100_interrupt()) needs to block
interrupts with spin_lock_irqsave(&priv->hw_lock, flags); ?
9) Instead of dev_info(&netdev->dev ...) , please consider netdev_info()
^ permalink raw reply
* Re: [PATCH v4] netfilter: ipt_CLUSTERIP: remove "no conntrack!"
From: Eric Dumazet @ 2011-01-13 14:39 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Netfilter Development Mailinglist, netdev,
Patrick McHardy
In-Reply-To: <alpine.LNX.2.01.1101131502240.25211@obet.zrqbmnf.qr>
Le jeudi 13 janvier 2011 à 15:02 +0100, Jan Engelhardt a écrit :
> On Thursday 2011-01-13 14:38, Eric Dumazet wrote:
>
> >Le jeudi 13 janvier 2011 à 12:54 +0100, Pablo Neira Ayuso a écrit :
> >
> >> But printing this does not provide any useful information. The first
> >> packet that does not belong to the cluster node that has received the
> >> packet, or the first invalid packet, will trigger this.
> >>
> >> Moreover, this confuses users since they can do nothing if they receive
> >> this message.
> >>
> >> Moreover, this target should be supersedes by the cluster match, which
> >> has been there for quite some time (it's also more flexible).
> >
> >Now you mentioned it, cluster match is not as flexible right now,
> >its hashing is on source_ip only.
>
> I think in that case, xt_cluster should be improved rather
> than an old module.
Amen
We should not improve IPv4 support then, I see.
My customers use this old module, and upgrading to xt_cluster is not an
option.
Should we discuss this forever or fix it ?
In the end, people are forced to add useless iptables rule to DROP
INVALID packets before entering ipt_CLUSTERIP, after googling or
eventually asking to experts.
Last time this was discussed, this went nowhere :
http://www.spinics.net/lists/netfilter/msg48676.html
Come on guys, we can do it, dont be afraid.
A non rate limited printk() in kernel is forbidden, especially in
network stack.
Then, cluster match can be improved, I am sure you already have a patch
for it.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Realtek r8168C / r8169 driver VLAN TAG stripping
From: Anand Raj Manickam @ 2011-01-13 14:40 UTC (permalink / raw)
To: netdev
Hi ,
I have a problem on Realtek 8168C chipset - r8169 Driver .
The VLAN tag on Tx & Rx gets stripped .
The 8021q module is loaded .
vconfig add eth0 50
ifconfig eth0.50 172.16.1.10 up
ping -I eth0.50 172.16.1.1 .
All packets on Tx & Rx have the VLAN tag stripped on Tx & Rx.
On debugging the Driver , we found that on Tx the VLAN tag is present.
static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
.
.
tp->tx_skb[entry].len = len;
txd->addr = cpu_to_le64(mapping);
txd->opts2 = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
printk("The Vlan tag %x \n",txd->opts2);
.
.
}
The Vlan tag 23200
In the above value 23200
2 - TxVlanTag
32 - Vlan tag (50).
>From the above we are clear that the Vlan tag reaches the driver .
Can someone shed some light on this issue ?
Any pointer are welcome.
Thanks,
Anand
^ permalink raw reply
* Re: [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-13 14:48 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294297998-26930-6-git-send-email-shawn.guo@freescale.com>
Hello,
hmm, this review comes to late, probably I will post a follow-up patch
for the low-hanging fruits at least.
On Thu, Jan 06, 2011 at 03:13:13PM +0800, Shawn Guo wrote:
> This patch is to add mx28 dual fec support. Here are some key notes
> for mx28 fec controller.
>
> - The mx28 fec controller naming ENET-MAC is a different IP from FEC
> used on other i.mx variants. But they are basically compatible
> on software interface, so it's possible to share the same driver.
> - ENET-MAC design on mx28 made an improper assumption that it runs
> on a big-endian system. As the result, driver has to swap every
> frame going to and coming from the controller.
> - The external phys can only be configured by fec0, which means fec1
> can not work independently and both phys need to be configured by
> mii_bus attached on fec0.
> - ENET-MAC reset will get mac address registers reset too.
> - ENET-MAC MII/RMII mode and 10M/100M speed are configured
> differently FEC.
> - ETHER_EN bit must be set to get ENET-MAC interrupt work.
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v4:
> - Use #ifndef CONFIG_ARM to include ColdFire header files
I intended you to not use CONFIG_ARCH_MXS at all, at least up to now
CONFIG_ARM works quite well.
> - Define quirk bits in id_entry.driver_data to handle controller
> difference, which is more scalable than using device name
> - Define fec0_mii_bus as a static function in fec_enet_mii_init
> to fold the mii_bus instance attached on fec0
IMHO not very good. At least the current code doesn't allow to have two
dual-fecs, because the 2nd dual-fec's slave would be attached to the 1st
dual-fec's mii_bus. Don't know a nice solution though. Probably you
either need a slave pointer in platform_data or have to treat a dual-fec
as only a single device.
> - Use cpu_to_be32 over __swab32 in function swap_buffer
>
> Changes for v3:
> - Move v2 changes into patch #3
> - Use device name to check if it's running on ENET-MAC
>
> drivers/net/Kconfig | 7 ++-
> drivers/net/fec.c | 148 +++++++++++++++++++++++++++++++++++++++++++++------
> drivers/net/fec.h | 5 +-
> 3 files changed, 139 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4f1755b..f34629b 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1944,18 +1944,19 @@ config 68360_ENET
> config FEC
> bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
> depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
> - MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5
> + MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC ? Again this calls for a
more global approach for these registration facilities.
> select PHYLIB
> help
> Say Y here if you want to use the built-in 10/100 Fast ethernet
> controller on some Motorola ColdFire and Freescale i.MX processors.
>
> config FEC2
> - bool "Second FEC ethernet controller (on some ColdFire CPUs)"
> + bool "Second FEC ethernet controller"
> depends on FEC
> help
> Say Y here if you want to use the second built-in 10/100 Fast
> - ethernet controller on some Motorola ColdFire processors.
> + ethernet controller on some Motorola ColdFire and Freescale
> + i.MX processors.
>
> config FEC_MPC52xx
> tristate "MPC52xx FEC driver"
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 8a1c51f..2a71373 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -17,6 +17,8 @@
> *
> * Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
> * Copyright (c) 2004-2006 Macq Electronique SA.
> + *
> + * Copyright (C) 2010 Freescale Semiconductor, Inc.
> */
>
> #include <linux/module.h>
> @@ -45,20 +47,36 @@
>
> #include <asm/cacheflush.h>
>
> -#ifndef CONFIG_ARCH_MXC
> +#ifndef CONFIG_ARM
> #include <asm/coldfire.h>
> #include <asm/mcfsim.h>
> #endif
>
> #include "fec.h"
>
> -#ifdef CONFIG_ARCH_MXC
> -#include <mach/hardware.h>
> +#if defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
> #define FEC_ALIGNMENT 0xf
> #else
> #define FEC_ALIGNMENT 0x3
> #endif
>
> +#define DRIVER_NAME "fec"
> +
> +/* Controller is ENET-MAC */
> +#define FEC_QUIRK_ENET_MAC (1 << 0)
does this really qualify to be a quirk?
> +/* Controller needs driver to swap frame */
> +#define FEC_QUIRK_SWAP_FRAME (1 << 1)
IMHO this is a bit misnamed. FEC_QUIRK_NEEDS_BE_DATA or similar would
be more accurate.
> +static struct platform_device_id fec_devtype[] = {
> + {
> + .name = DRIVER_NAME,
> + .driver_data = 0,
> + }, {
> + .name = "imx28-fec",
> + .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
> + }
> +};
> +
> static unsigned char macaddr[ETH_ALEN];
> module_param_array(macaddr, byte, NULL, 0);
> MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> @@ -129,7 +147,8 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
> * account when setting it.
> */
> #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
> - defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARCH_MXC)
> + defined(CONFIG_M520x) || defined(CONFIG_M532x) || \
> + defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
I wonder what is excluded here. FEC depends on
M523x || M527x || M5272 || M528x || M520x || M532x || \
MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
so the only difference is that the latter lists M5272 which seems a bit
redundant in the presence of M527x.
> #define OPT_FRAME_SIZE (PKT_MAXBUF_SIZE << 16)
> #else
> #define OPT_FRAME_SIZE 0
> @@ -208,10 +227,23 @@ static void fec_stop(struct net_device *dev);
> /* Transmitter timeout */
> #define TX_TIMEOUT (2 * HZ)
>
> +static void *swap_buffer(void *bufaddr, int len)
> +{
> + int i;
> + unsigned int *buf = bufaddr;
> +
> + for (i = 0; i < (len + 3) / 4; i++, buf++)
> + *buf = cpu_to_be32(*buf);
if len isn't a multiple of 4 this accesses bytes behind len. Is this
generally OK here? (E.g. because skbs always have a length that is a
multiple of 4?)
> +
> + return bufaddr;
> +}
> +
> static netdev_tx_t
> fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct fec_enet_private *fep = netdev_priv(dev);
> + const struct platform_device_id *id_entry =
> + platform_get_device_id(fep->pdev);
> struct bufdesc *bdp;
> void *bufaddr;
> unsigned short status;
> @@ -256,6 +288,14 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> bufaddr = fep->tx_bounce[index];
> }
>
> + /*
> + * Some design made an incorrect assumption on endian mode of
> + * the system that it's running on. As the result, driver has to
> + * swap every frame going to and coming from the controller.
> + */
> + if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
> + swap_buffer(bufaddr, skb->len);
> +
> /* Save skb pointer */
> fep->tx_skbuff[fep->skb_cur] = skb;
>
> @@ -424,6 +464,8 @@ static void
> fec_enet_rx(struct net_device *dev)
> {
> struct fec_enet_private *fep = netdev_priv(dev);
> + const struct platform_device_id *id_entry =
> + platform_get_device_id(fep->pdev);
> struct bufdesc *bdp;
> unsigned short status;
> struct sk_buff *skb;
> @@ -487,6 +529,9 @@ fec_enet_rx(struct net_device *dev)
> dma_unmap_single(NULL, bdp->cbd_bufaddr, bdp->cbd_datlen,
> DMA_FROM_DEVICE);
>
> + if (id_entry->driver_data & FEC_QUIRK_SWAP_FRAME)
> + swap_buffer(data, pkt_len);
> +
> /* This does 16 byte alignment, exactly what we need.
> * The packet length includes FCS, but we don't want to
> * include that when passing upstream as it messes up
> @@ -689,6 +734,7 @@ static int fec_enet_mii_probe(struct net_device *dev)
> char mdio_bus_id[MII_BUS_ID_SIZE];
> char phy_name[MII_BUS_ID_SIZE + 3];
> int phy_id;
> + int dev_id = fep->pdev->id;
>
> fep->phy_dev = NULL;
>
> @@ -700,6 +746,8 @@ static int fec_enet_mii_probe(struct net_device *dev)
> continue;
> if (fep->mii_bus->phy_map[phy_id]->phy_id == 0)
> continue;
> + if (dev_id--)
> + continue;
> strncpy(mdio_bus_id, fep->mii_bus->id, MII_BUS_ID_SIZE);
> break;
> }
> @@ -737,10 +785,35 @@ static int fec_enet_mii_probe(struct net_device *dev)
>
> static int fec_enet_mii_init(struct platform_device *pdev)
> {
> + static struct mii_bus *fec0_mii_bus;
> struct net_device *dev = platform_get_drvdata(pdev);
> struct fec_enet_private *fep = netdev_priv(dev);
> + const struct platform_device_id *id_entry =
> + platform_get_device_id(fep->pdev);
> int err = -ENXIO, i;
>
> + /*
> + * The dual fec interfaces are not equivalent with enet-mac.
> + * Here are the differences:
> + *
> + * - fec0 supports MII & RMII modes while fec1 only supports RMII
> + * - fec0 acts as the 1588 time master while fec1 is slave
> + * - external phys can only be configured by fec0
> + *
> + * That is to say fec1 can not work independently. It only works
> + * when fec0 is working. The reason behind this design is that the
> + * second interface is added primarily for Switch mode.
> + *
> + * Because of the last point above, both phys are attached on fec0
> + * mdio interface in board design, and need to be configured by
> + * fec0 mii_bus.
> + */
> + if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
> + /* fec1 uses fec0 mii_bus */
> + fep->mii_bus = fec0_mii_bus;
> + return 0;
What happens if imx28-fec.1 is probed before imx28-fec.0?
> + }
> +
> fep->mii_timeout = 0;
>
> /*
> @@ -777,6 +850,10 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> if (mdiobus_register(fep->mii_bus))
> goto err_out_free_mdio_irq;
>
> + /* save fec0 mii_bus */
> + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
> + fec0_mii_bus = fep->mii_bus;
> +
> return 0;
>
> err_out_free_mdio_irq:
> @@ -1148,12 +1225,25 @@ static void
> fec_restart(struct net_device *dev, int duplex)
> {
> struct fec_enet_private *fep = netdev_priv(dev);
> + const struct platform_device_id *id_entry =
> + platform_get_device_id(fep->pdev);
> int i;
> + u32 val, temp_mac[2];
>
> /* Whack a reset. We should wait for this. */
> writel(1, fep->hwp + FEC_ECNTRL);
> udelay(10);
>
> + /*
> + * enet-mac reset will reset mac address registers too,
> + * so need to reconfigure it.
> + */
> + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
> + }
> +
> /* Clear any outstanding interrupt. */
> writel(0xffc00000, fep->hwp + FEC_IEVENT);
>
> @@ -1200,20 +1290,45 @@ fec_restart(struct net_device *dev, int duplex)
> /* Set MII speed */
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> -#ifdef FEC_MIIGSK_ENR
> - if (fep->phy_interface == PHY_INTERFACE_MODE_RMII) {
> - /* disable the gasket and wait */
> - writel(0, fep->hwp + FEC_MIIGSK_ENR);
> - while (readl(fep->hwp + FEC_MIIGSK_ENR) & 4)
> - udelay(1);
> + /*
> + * The phy interface and speed need to get configured
> + * differently on enet-mac.
> + */
> + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> + val = readl(fep->hwp + FEC_R_CNTRL);
>
> - /* configure the gasket: RMII, 50 MHz, no loopback, no echo */
> - writel(1, fep->hwp + FEC_MIIGSK_CFGR);
> + /* MII or RMII */
> + if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
> + val |= (1 << 8);
Can we have a #define for 1 << 8 please?
> + else
> + val &= ~(1 << 8);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v5] ARM: mx28: add the second fec device registration
From: Uwe Kleine-König @ 2011-01-13 14:49 UTC (permalink / raw)
To: Shawn Guo
Cc: s.hauer, davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw,
w.sang, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294747764-4499-1-git-send-email-shawn.guo@freescale.com>
On Tue, Jan 11, 2011 at 08:09:24PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v5:
> - Do not use CONFIG_FEC2 which is a fec driver configration
>
> arch/arm/mach-mxs/mach-mx28evk.c | 26 +++++++++++++++++++++++---
> 1 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> index d162e95..8e2c597 100644
> --- a/arch/arm/mach-mxs/mach-mx28evk.c
> +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> @@ -57,6 +57,19 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> MX28_PAD_ENET_CLK__CLKCTRL_ENET |
> (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + /* fec1 */
> + MX28_PAD_ENET0_CRS__ENET1_RX_EN |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX28_PAD_ENET0_RXD2__ENET1_RXD0 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX28_PAD_ENET0_RXD3__ENET1_RXD1 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX28_PAD_ENET0_COL__ENET1_TX_EN |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX28_PAD_ENET0_TXD2__ENET1_TXD0 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> + MX28_PAD_ENET0_TXD3__ENET1_TXD1 |
> + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> /* phy power line */
> MX28_PAD_SSP1_DATA3__GPIO_2_15 |
> (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> @@ -106,8 +119,14 @@ static void __init mx28evk_fec_reset(void)
> gpio_set_value(MX28EVK_FEC_PHY_RESET, 1);
> }
>
> -static const struct fec_platform_data mx28_fec_pdata __initconst = {
> - .phy = PHY_INTERFACE_MODE_RMII,
> +static struct fec_platform_data mx28_fec_pdata[] = {
this can still be initdata, doesn't it?
> + {
> + /* fec0 */
> + .phy = PHY_INTERFACE_MODE_RMII,
> + }, {
> + /* fec1 */
> + .phy = PHY_INTERFACE_MODE_RMII,
> + },
> };
>
> static void __init mx28evk_init(void)
> @@ -117,7 +136,8 @@ static void __init mx28evk_init(void)
> mx28_add_duart();
>
> mx28evk_fec_reset();
> - mx28_add_fec(0, &mx28_fec_pdata);
> + mx28_add_fec(0, &mx28_fec_pdata[0]);
> + mx28_add_fec(1, &mx28_fec_pdata[1]);
> }
>
> static void __init mx28evk_timer_init(void)
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v4 09/10] ARM: mx28: read fec mac address from ocotp
From: Uwe Kleine-König @ 2011-01-13 14:50 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294297998-26930-10-git-send-email-shawn.guo@freescale.com>
Hello Shawn,
$SUBJECT ~= s,mx28,mxs/mx28evk, please
On Thu, Jan 06, 2011 at 03:13:17PM +0800, Shawn Guo wrote:
> Read fec mac address from ocotp and save it into fec_platform_data
> mac field for fec driver to use.
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v2:
> - It's not necessary to remove "const" for fec_platform_data from
> platform-fec.c and devices-common.h, so add it back.
> - Hard-coding Freescale OUI (00:04:9f) instead of just the first
> two two octets.
> - Correct the return of mx28evk_fec_get_mac() and check it
> with caller
>
> arch/arm/mach-mxs/mach-mx28evk.c | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> index def6519..54fa512 100644
> --- a/arch/arm/mach-mxs/mach-mx28evk.c
> +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> @@ -129,12 +129,44 @@ static struct fec_platform_data mx28_fec_pdata[] = {
> },
> };
>
> +static int __init mx28evk_fec_get_mac(void)
> +{
> + int i, ret;
> + u32 val;
> +
> + /*
> + * OCOTP only stores the last 4 octets for each mac address,
> + * so hard-code Freescale OUI (00:04:9f) here.
> + */
> + for (i = 0; i < 2; i++) {
> + ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
> + if (ret)
> + goto error;
> +
> + mx28_fec_pdata[i].mac[0] = 0x00;
> + mx28_fec_pdata[i].mac[1] = 0x04;
> + mx28_fec_pdata[i].mac[2] = 0x9f;
> + mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
> + mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
> + mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
> + }
> +
> + return 0;
> +
> +error:
> + pr_err("%s: timeout when reading fec mac from OCOTP\n", __func__);
> + return ret;
> +}
> +
> static void __init mx28evk_init(void)
> {
> mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
>
> mx28_add_duart();
>
> + if (mx28evk_fec_get_mac())
> + pr_warn("%s: failed on fec mac setup\n", __func__);
> +
> mx28evk_fec_reset();
> mx28_add_fec(0, &mx28_fec_pdata[0]);
> #ifdef CONFIG_FEC2
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Jesse Gross @ 2011-01-13 15:06 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Leun, Michael Chan, Eric Dumazet, David Miller,
Ben Greear, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20110113012157.GA28147@mcarlson.broadcom.com>
On Wed, Jan 12, 2011 at 8:21 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Thu, Jan 06, 2011 at 08:36:27PM -0800, Jesse Gross wrote:
>> On Thu, Jan 6, 2011 at 10:24 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
>> > On Sat, Dec 18, 2010 at 07:38:00PM -0800, Jesse Gross wrote:
>> >> On Tue, Dec 14, 2010 at 11:16 PM, Michael Leun
>> >> <lkml20101129@newton.leun.net> wrote:
>> >> > OK - all tests done on that DL320G5:
>> >> >
>> >> > For completeness, 2.6.37-rc5 unpatched:
>> >> >
>> >> > eth0, no vlan configured: totally broken - see double tagged vlans
>> >> > without tag, single or untagged packets missing at all
>> >>
>> >> Random behavior? ?This one is somewhat hard to explain - maybe there
>> >> are some other factors. ?eth0 has ASF on, so it always strips tags. ?I
>> >> would expect it to behave like the vlan configured case.
>> >>
>> >> >
>> >> > eth0, vlan configured: see packets without vlan tag (see double tagged
>> >> > packets with one vlan tag)
>> >>
>> >> Both ASF and vlan group configured cause tag stripping to be enabled.
>> >> Missing tag.
>> >>
>> >> >
>> >> > eth1 same as originally reported:
>> >> > without vlan configured see vlan tags (single and double tagged as
>> >> > expected)
>> >>
>> >> No ASF and no vlan group means tag stripping is disabled. ?Have tag.
>> >>
>> >> > with vlan configured: see packets without vlan tag (see double tagged
>> >> > packets with one vlan tag)
>> >>
>> >> Configuring vlan group causes stripping to be enabled. ?Missing tag.
>> >>
>> >> >
>> >> >
>> >> > 2.6.37-rc5, your tg3 use new vlan-code patch:
>> >> >
>> >> > eth0, no vlan configured: ?see packets without vlan tag (see double
>> >> > tagged packets with one vlan tag)
>> >>
>> >> ASF enables tag stripping. ?Missing tag.
>> >>
>> >> > eth1, no vlan configured: see vlan tags (single and double tagged as
>> >> > expected)
>> >>
>> >> No ASF, no vlan group means no stripping. ?Have tag.
>> >>
>> >> >
>> >> >
>> >> > eth0, vlan configured: as without vlan
>> >>
>> >> ASF enables stripping. ?Missing tag.
>> >>
>> >> > eth1, vlan configured: as without vlan
>> >>
>> >> With this patch vlan stripping is only enabled when ASF is on, so no
>> >> stripping. ?Have tag.
>> >>
>> >> >
>> >> > 2.6.37-rc5, your tg3 use new vlan-code patch with test patch ontop
>> >> >
>> >> > eth1 no vlan configured: see packets without vlan tag (see double tagged
>> >> > packets with one vlan tag)
>> >>
>> >> With the second patch, vlan stripping is always enabled. ?Missing tag.
>> >>
>> >> > eth1 with vlan: the same
>> >>
>> >> Stripping still always enabled. ?Missing tag.
>> >>
>> >> The bottom line is whenever vlan stripping is enabled we're missing
>> >> the outer tag. ?It might be worth adding some debugging in the area
>> >> before napi_gro_receive/vlan_gro_receive (depending on version). ?My
>> >> guess is that (desc->type_flags & RXD_FLAG_VLAN) is false even for
>> >> vlan packets on this NIC.
>> >>
>> >> You said that everything works on the 5752? ?Matt, is it possible that
>> >> the 5714 either has a problem with vlan stripping or a different way
>> >> of reporting it?
>> >
>> > I don't think this is a 5714 specific issue. ?I think the problem is
>> > rooted in the fact that the VLAN tag stripping is enabled.
>>
>> It's definitely related to vlan stripping being enabled. Other cards
>> using tg3 seem to work fine with stripping though, which is why I
>> thought it might be specific to the 5714.
>
> I just tested this on a 5714S, using a net-next-2.6 snapshot obtained
> today. It does the right thing in both cases (2nd tg3 patch ommited /
> applied). The tag is always visible in the packet stream as seen from
> tcpdump.
>
>> > Your RXD_FLAG_VLAN idea sounds unlikely to me, but it's worth a check.
>> >
>> > The patch here is using __vlan_hwaccel_put_tag(), which informs the
>> > stack a VLAN tag is present. ?If this is indeed a reporting problem, I'm
>> > not sure what else the driver should be doing.
>>
>> The code to hand off the tag to the stack looks OK to me. Michael was
>> seeing this on older versions of the kernel as well with this NIC,
>> which predates both this patch and the larger vlan changes so it
>> doesn't seem like a problem with passing the tag to the network stack.
>> It's hard to know exactly what is going on though without seeing what
>> the hardware is reporting.
>
> When RX_MODE_KEEP_VLAN_TAG is set, the RXD_FLAG_VLAN flag will not be set
> when receiving a packet. The driver skips the __vlan_hwaccel_put_tag()
> call.
>
> When RX_MODE_KEEP_VLAN_TAG is unset, the RXD_FLAG_VLAN flag is set, and
> __vlan_hwaccel_put_tag() is called to reinject the packet.
OK, thanks for testing it out. I'm not sure that there's anything
more we can do without hearing from Michael.
^ permalink raw reply
* Re: [PATCH v4 06/10] ARM: mx28: update clock and device name for dual fec support
From: Uwe Kleine-König @ 2011-01-13 15:06 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294297998-26930-7-git-send-email-shawn.guo@freescale.com>
Hi Shawn,
On Thu, Jan 06, 2011 at 03:13:14PM +0800, Shawn Guo wrote:
> Change device name from "fec" to "imx28-fec", so that fec driver
> can distinguish mx28.
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v4:
> - Use "imx28-fec" as fec device name
>
> Changes for v3:
> - Change device name to "enet-mac"
>
> arch/arm/mach-mxs/clock-mx28.c | 3 ++-
> arch/arm/mach-mxs/devices/platform-fec.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/clock-mx28.c b/arch/arm/mach-mxs/clock-mx28.c
> index f20b254..e2a8b0f 100644
> --- a/arch/arm/mach-mxs/clock-mx28.c
> +++ b/arch/arm/mach-mxs/clock-mx28.c
> @@ -606,7 +606,8 @@ static struct clk_lookup lookups[] = {
> _REGISTER_CLOCK("duart", "apb_pclk", xbus_clk)
> /* for amba-pl011 driver */
> _REGISTER_CLOCK("duart", NULL, uart_clk)
> - _REGISTER_CLOCK("fec.0", NULL, fec_clk)
> + _REGISTER_CLOCK("imx28-fec.0", NULL, fec_clk)
> + _REGISTER_CLOCK("imx28-fec.1", NULL, fec_clk)
> _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> _REGISTER_CLOCK("pll2", NULL, pll2_clk)
> _REGISTER_CLOCK(NULL, "hclk", hbus_clk)
> diff --git a/arch/arm/mach-mxs/devices/platform-fec.c b/arch/arm/mach-mxs/devices/platform-fec.c
> index c08168c..c42dff7 100644
> --- a/arch/arm/mach-mxs/devices/platform-fec.c
> +++ b/arch/arm/mach-mxs/devices/platform-fec.c
> @@ -45,6 +45,6 @@ struct platform_device *__init mxs_add_fec(
> },
> };
>
> - return mxs_add_platform_device("fec", data->id,
> + return mxs_add_platform_device("imx28-fec", data->id,
IMHO "imx28-fec" shouldn't be hard coded here but come from data. See
imx-spi device registration for an example.
Uwe
> res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
> }
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: STMMAC driver: NFS Problem on 2.6.37
From: Chuck Lever @ 2011-01-13 15:07 UTC (permalink / raw)
To: deepaksi
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
Armando VISCONTI, Shiraz HASHIM, Viresh KUMAR
In-Reply-To: <4D2EC133.7010607-qxv4g6HH51o@public.gmane.org>
On Jan 13, 2011, at 4:09 AM, deepaksi wrote:
> Hi
>
> I am facing a problem related to nfs boot, while using the stmmac driver
> ported on 2.6.37 kernel. When we use a JFFS2 file system and mount the kernel,
> the network driver works fine.
>
> I have been following the mailing list and could find some issues with NFS
> on 2.6.37 but I am not too sure whether the kernel crash I am getting is
> related to that.
>
> The driver worked fine on 2.6.32 kernel, but while booting the 2.6.37
> kernel I get the following log messages:
>
> stmmac: Rx Checksum Offload Engine supported
> TX Checksum insertion supported
> IP-Config: Complete:
> device=eth0, addr=192.168.1.10, mask=255.255.255.0, gw=255.255.255.255,
> host=192.168.1.10, domain=, nis-domain=(none),
> bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
Why is rootpath left undefined?
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option; here are the available
> partitions:
> 1f00 64 mtdblock0 (driver?)
> 1f01 256 mtdblock1 (driver?)
> 1f02 2816 mtdblock2 (driver?)
> 1f03 5056 mtdblock3 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c7b5b000 r6:00000000 r5:c7b5b015 r4:c04296b8
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c004ebf8>] (panic+0x60/0x180)
> [<c004eb98>] (panic+0x0/0x180) from [<c0009114>]
> (mount_block_root+0x1d4/0x214)
> r3:00000000 r2:00000001 r1:c782bf50 r0:c0394851
> [<c0008f40>] (mount_block_root+0x0/0x214) from [<c00091fc>]
> (mount_root+0xa8/0xc8)
> [<c0009154>] (mount_root+0x0/0xc8) from [<c0009388>]
> (prepare_namespace+0x16c/0x1d0)
> r4:c04288c0
> [<c000921c>] (prepare_namespace+0x0/0x1d0) from [<c0008904>]
> (kernel_init+0x1cc/0x220)
> r5:c0402048 r4:c0428860
> [<c0008738>] (kernel_init+0x0/0x220) from [<c00522a8>] (do_exit+0x0/0x5e0)
> r7:00000013 r6:c00522a8 r5:c0008738 r4:00000000
> CPU0: stopping
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c0405484 r6:00000406 r5:00000000 r4:00000000
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c002d334>] (do_IPI+0xb4/0x124)
> [<c002d280>] (do_IPI+0x0/0x124) from [<c0032bb4>] (__irq_svc+0x34/0xc0)
> Exception stack(0xc03f3f50 to 0xc03f3f98)
> 3f40: c0402048 00000000 c03f3f98
> 00000000
> 3f60: c03f2000 c04288dc c0027290 c0405484 000258e8 411fc091 00000000
> c03f3fa4
> 3f80: c03f3fa8 c03f3f98 c0034a24 c0034a28 60000013 ffffffff
> r5:fc800100 r4:ffffffff
> [<c00349fc>] (default_idle+0x0/0x30) from [<c0034874>] (cpu_idle+0x80/0xc0)
> [<c00347f4>] (cpu_idle+0x0/0xc0) from [<c030602c>] (rest_init+0x64/0x7c)
> r5:c04288dc r4:c04020b0
> [<c0305fc8>] (rest_init+0x0/0x7c) from [<c0008bd4>]
> (start_kernel+0x27c/0x2d8)
> [<c0008958>] (start_kernel+0x0/0x2d8) from [<00008038>] (0x8038)
> r5:c0401fac r4:10c5387d
>
> I have tried the same over latest source picked from linus tree,
> 4162cf64973df51fc885825bc9ca4d055891c49f
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>
> We are using version 3 of the NFs protocol in kernel's NFS client.
>
>
> Regards
> Deepak
> ST Microelectronics
>
> .
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Realtek r8168C / r8169 driver VLAN TAG stripping
From: Anand Raj Manickam @ 2011-01-13 15:09 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTi=qVSEh=RyzJ6y4kQvJW+hxqWMh2gAMmhk7GGob@mail.gmail.com>
Sorry,
This happens on a Linux 2.6.30.8 kernel .The driver is in-kernel.
On Thu, Jan 13, 2011 at 8:10 PM, Anand Raj Manickam <anandrm@gmail.com> wrote:
> Hi ,
> I have a problem on Realtek 8168C chipset - r8169 Driver .
> The VLAN tag on Tx & Rx gets stripped .
>
> The 8021q module is loaded .
> vconfig add eth0 50
> ifconfig eth0.50 172.16.1.10 up
>
> ping -I eth0.50 172.16.1.1 .
>
> All packets on Tx & Rx have the VLAN tag stripped on Tx & Rx.
>
> On debugging the Driver , we found that on Tx the VLAN tag is present.
>
> static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> .
> .
> tp->tx_skb[entry].len = len;
> txd->addr = cpu_to_le64(mapping);
> txd->opts2 = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
> printk("The Vlan tag %x \n",txd->opts2);
> .
> .
> }
>
> The Vlan tag 23200
>
> In the above value 23200
> 2 - TxVlanTag
> 32 - Vlan tag (50).
>
> From the above we are clear that the Vlan tag reaches the driver .
>
> Can someone shed some light on this issue ?
> Any pointers are welcome.
> Thanks,
> Anand
>
^ permalink raw reply
* Re: [PATCH v4 08/10] ARM: mxs: add ocotp read function
From: Uwe Kleine-König @ 2011-01-13 15:19 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294297998-26930-9-git-send-email-shawn.guo@freescale.com>
On Thu, Jan 06, 2011 at 03:13:16PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> Changes for v4:
> - Call cpu_relax() during polling
>
> Changes for v2:
> - Add mutex locking for mxs_read_ocotp()
> - Use type size_t for count and i
> - Add comment for clk_enable/disable skipping
> - Add ERROR bit clearing and polling step
>
> arch/arm/mach-mxs/Makefile | 2 +-
> arch/arm/mach-mxs/include/mach/common.h | 1 +
> arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> 3 files changed, 81 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-mxs/ocotp.c
>
> diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> index 39d3f9c..f23ebbd 100644
> --- a/arch/arm/mach-mxs/Makefile
> +++ b/arch/arm/mach-mxs/Makefile
> @@ -1,5 +1,5 @@
> # Common support
> -obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
> +obj-y := clock.o devices.o gpio.o icoll.o iomux.o ocotp.o system.o timer.o
is it worth to make ocotp optional? (and let evk select
CONFIG_MXS_OCOTP)
Best regards
Uwe
>
> obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
> obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
> diff --git a/arch/arm/mach-mxs/include/mach/common.h b/arch/arm/mach-mxs/include/mach/common.h
> index 59133eb..cf02552 100644
> --- a/arch/arm/mach-mxs/include/mach/common.h
> +++ b/arch/arm/mach-mxs/include/mach/common.h
> @@ -13,6 +13,7 @@
>
> struct clk;
>
> +extern int mxs_read_ocotp(int offset, int count, u32 *values);
> extern int mxs_reset_block(void __iomem *);
> extern void mxs_timer_init(struct clk *, int);
>
> diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
> new file mode 100644
> index 0000000..e2d39aa
> --- /dev/null
> +++ b/arch/arm/mach-mxs/ocotp.c
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/mutex.h>
> +
> +#include <mach/mxs.h>
> +
> +#define BM_OCOTP_CTRL_BUSY (1 << 8)
> +#define BM_OCOTP_CTRL_ERROR (1 << 9)
> +#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
> +
> +static DEFINE_MUTEX(ocotp_mutex);
> +
> +int mxs_read_ocotp(unsigned offset, size_t count, u32 *values)
> +{
> + void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
> + int timeout = 0x400;
> + size_t i;
> +
> + mutex_lock(&ocotp_mutex);
> +
> + /*
> + * clk_enable(hbus_clk) for ocotp can be skipped
> + * as it must be on when system is running.
> + */
> +
> + /* try to clear ERROR bit */
> + __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
> +
> + /* check both BUSY and ERROR cleared */
> + while ((__raw_readl(ocotp_base) &
> + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> + cpu_relax();
> +
> + if (unlikely(!timeout))
> + goto error_unlock;
> +
> + /* open OCOTP banks for read */
> + __mxs_setl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
> +
> + /* approximately wait 32 hclk cycles */
> + udelay(1);
> +
> + /* poll BUSY bit becoming cleared */
> + timeout = 0x400;
> + while ((__raw_readl(ocotp_base) & BM_OCOTP_CTRL_BUSY) && --timeout)
> + cpu_relax();
> +
> + if (unlikely(!timeout))
> + goto error_unlock;
> +
> + for (i = 0; i < count; i++, offset += 4)
> + *values++ = __raw_readl(ocotp_base + offset);
> +
> + /* close banks for power saving */
> + __mxs_clrl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
> +
> + mutex_unlock(&ocotp_mutex);
> +
> + return 0;
> +
> +error_unlock:
> + mutex_unlock(&ocotp_mutex);
> + pr_err("%s: timeout in reading OCOTP\n", __func__);
> + return -ETIMEDOUT;
> +}
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Joe Perches @ 2011-01-13 15:39 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294919372-1904-1-git-send-email-ratbert.chuang@gmail.com>
On Thu, 2011-01-13 at 19:49 +0800, Po-Yu Chuang wrote:
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII. This driver has been working on some ARM/NDS32 SoC including
> Faraday A320 and Andes AG101.
A couple of trivial comments not already mentioned by others.
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
[]
> @@ -2014,6 +2014,15 @@ config BCM63XX_ENET
> This driver supports the ethernet MACs in the Broadcom 63xx
> MIPS chipset family (BCM63XX).
>
> +config FTMAC100
> + tristate "Faraday FTMAC100 10/100 Ethernet support"
> + depends on ARM
> + select MII
> + help
> + This driver supports the FTMAC100 Ethernet controller from
> + Faraday. It is used on Faraday A320, Andes AG101, AG101P
> + and some other ARM/NDS32 SoC's.
> +
ARM specific net drivers are for now in drivers/net/arm/
Perhaps it's better to locate these files there?
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
[]
> +static int ftmac100_rx_packet_error(struct ftmac100 *priv,
> + struct ftmac100_rxdes *rxdes)
> +{
> + struct device *dev = &priv->netdev->dev;
> + int error = 0;
> +
> + if (unlikely(ftmac100_rxdes_rx_error(rxdes))) {
> + if (printk_ratelimit())
> + dev_info(dev, "rx err\n");
There are many printk_ratelimit() tests.
It's better to use net_ratelimit() or a local ratelimit_state
so there's less possible suppression of other subsystem
messages.
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Jesse Gross @ 2011-01-13 15:45 UTC (permalink / raw)
To: Simon Horman
Cc: Eric Dumazet, Rusty Russell, virtualization, dev, virtualization,
netdev, kvm, Michael S. Tsirkin
In-Reply-To: <20110113064718.GA17905@verge.net.au>
On Thu, Jan 13, 2011 at 1:47 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Jan 10, 2011 at 06:31:55PM +0900, Simon Horman wrote:
>> On Fri, Jan 07, 2011 at 10:23:58AM +0900, Simon Horman wrote:
>> > On Thu, Jan 06, 2011 at 05:38:01PM -0500, Jesse Gross wrote:
>> >
>> > [ snip ]
>> > >
>> > > I know that everyone likes a nice netperf result but I agree with
>> > > Michael that this probably isn't the right question to be asking. I
>> > > don't think that socket buffers are a real solution to the flow
>> > > control problem: they happen to provide that functionality but it's
>> > > more of a side effect than anything. It's just that the amount of
>> > > memory consumed by packets in the queue(s) doesn't really have any
>> > > implicit meaning for flow control (think multiple physical adapters,
>> > > all with the same speed instead of a virtual device and a physical
>> > > device with wildly different speeds). The analog in the physical
>> > > world that you're looking for would be Ethernet flow control.
>> > > Obviously, if the question is limiting CPU or memory consumption then
>> > > that's a different story.
>> >
>> > Point taken. I will see if I can control CPU (and thus memory) consumption
>> > using cgroups and/or tc.
>>
>> I have found that I can successfully control the throughput using
>> the following techniques
>>
>> 1) Place a tc egress filter on dummy0
>>
>> 2) Use ovs-ofctl to add a flow that sends skbs to dummy0 and then eth1,
>> this is effectively the same as one of my hacks to the datapath
>> that I mentioned in an earlier mail. The result is that eth1
>> "paces" the connection.
>
> Further to this, I wonder if there is any interest in providing
> a method to switch the action order - using ovs-ofctl is a hack imho -
> and/or switching the default action order for mirroring.
I'm not sure that there is a way to do this that is correct in the
generic case. It's possible that the destination could be a VM while
packets are being mirrored to a physical device or we could be
multicasting or some other arbitrarily complex scenario. Just think
of what a physical switch would do if it has ports with two different
speeds.
^ permalink raw reply
* [PATCH] tcp: remove duplicate th = tcp_hdr(skb)
From: Christoph Paasch @ 2011-01-13 15:41 UTC (permalink / raw)
To: davem, netdev; +Cc: Christoph Paasch
th is already set some lines before to be th = tcp_hdr(skb).
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
net/ipv4/tcp_ipv4.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 856f684..7fe29c6 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1644,7 +1644,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
if (!skb_csum_unnecessary(skb) && tcp_v4_checksum_init(skb))
goto bad_packet;
- th = tcp_hdr(skb);
iph = ip_hdr(skb);
TCP_SKB_CB(skb)->seq = ntohl(th->seq);
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] tcp: remove duplicate th = tcp_hdr(skb)
From: Jesse Gross @ 2011-01-13 15:54 UTC (permalink / raw)
To: Christoph Paasch; +Cc: davem, netdev
In-Reply-To: <1294933302-28469-1-git-send-email-christoph.paasch@uclouvain.be>
On Thu, Jan 13, 2011 at 10:41 AM, Christoph Paasch
<christoph.paasch@uclouvain.be> wrote:
> th is already set some lines before to be th = tcp_hdr(skb).
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> net/ipv4/tcp_ipv4.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 856f684..7fe29c6 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1644,7 +1644,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
> if (!skb_csum_unnecessary(skb) && tcp_v4_checksum_init(skb))
> goto bad_packet;
>
> - th = tcp_hdr(skb);
It needs to be reloaded because pskb_may_pull() may reallocate the buffer.
^ permalink raw reply
* Re: [RFC] net_sched: mark packet staying on queue too long
From: Eric Dumazet @ 2011-01-13 15:54 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, Stephen Hemminger, hadi, Jarek Poplawski,
David Miller, netdev
In-Reply-To: <4D2EE708.8010806@trash.net>
Le jeudi 13 janvier 2011 à 12:50 +0100, Patrick McHardy a écrit :
> On 04.01.2011 15:19, Jesper Dangaard Brouer wrote:
> >> ...
> >> You might want to look into CHOKe and ECSFQ which are other AQM models
> >> that have shown up in research.
> >
> > Have you looked at the SFB (Stochastic Fair Blue) implementation by Juliusz Chroboczek?
> >
> > http://www.pps.jussieu.fr/~jch/software/sfb/
>
> I had a closer look at this some time ago and noticed a couple of bugs
> (f.i. double buffering might be enabled or disabled or the buffers
> switched while a packet is queued, so on dequeue the wrong buffer will
> have its queue length decremented) and also found the hashing quite
> inefficient, so I've implemented my own version. There's still a minor
> bug somewhere, but if people are interested I could finish it some
> time soon and post the patches.
I am very interested Patrick, I also found SFB hashing inefficient, so
any new idea is welcomed.
We should get more schedulers at hand.
CHOKe is about to be released, QFQ is also coming soon, thanks to
Stephen (and respective AQM authors)
Thanks
^ permalink raw reply
* Re: [PATCH] tcp: remove duplicate th = tcp_hdr(skb)
From: Eric Dumazet @ 2011-01-13 15:59 UTC (permalink / raw)
To: Christoph Paasch; +Cc: davem, netdev
In-Reply-To: <1294933302-28469-1-git-send-email-christoph.paasch@uclouvain.be>
Le jeudi 13 janvier 2011 à 16:41 +0100, Christoph Paasch a écrit :
> th is already set some lines before to be th = tcp_hdr(skb).
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> net/ipv4/tcp_ipv4.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 856f684..7fe29c6 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1644,7 +1644,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
> if (!skb_csum_unnecessary(skb) && tcp_v4_checksum_init(skb))
> goto bad_packet;
>
Well... no please.
> - th = tcp_hdr(skb);
> iph = ip_hdr(skb);
> TCP_SKB_CB(skb)->seq = ntohl(th->seq);
> TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
Hint : pskb_may_pull() can change tcp_hdr(skb) result.
^ 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