* Re: [PATCH V3] wanrouter: Remove it and the drivers that depend on it
From: David Miller @ 2012-11-14 1:44 UTC (permalink / raw)
To: paul.gortmaker; +Cc: joe, netdev
In-Reply-To: <CAP=VYLqiLpVn99bp08gkSQ+jLFiw8T7vsohJ6e+TdzOtyDwKBQ@mail.gmail.com>
Paul, you can't have HTML content to the list and one of your MIME
sections was HTML, so it was rejected by vger's filters.
Please repost with the HTML stuff removed.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: Michael Chan @ 2012-11-14 1:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121113.202408.79469396824848499.davem@davemloft.net>
On Tue, 2012-11-13 at 20:24 -0500, David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Tue, 13 Nov 2012 15:40:29 -0800
>
> > I suppose we can just put the SAN MAC into the real netdev->dev_addr so
> > that the VLAN will automatically get it. But this doesn't seem very
> > nice as we would be pretending to have a normal MAC address (for
> > networking) in this SAN device. The networking MAC address is in a
> > different PCI function.
>
> I certainly would prefer if you took that approach. At least in that
> way the addressing of the netdev objects would appear more consistent.
>
Ok. To be more complete, I think we need to add a flag or something to
such a netdev to indicate that it is a SAN device only. What's your
opinion on that?
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: John Fastabend @ 2012-11-14 1:58 UTC (permalink / raw)
To: Michael Chan; +Cc: David Miller, netdev
In-Reply-To: <1352857850.6276.71.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On 11/13/2012 5:50 PM, Michael Chan wrote:
> On Tue, 2012-11-13 at 20:24 -0500, David Miller wrote:
>> From: "Michael Chan" <mchan@broadcom.com>
>> Date: Tue, 13 Nov 2012 15:40:29 -0800
>>
>>> I suppose we can just put the SAN MAC into the real netdev->dev_addr so
>>> that the VLAN will automatically get it. But this doesn't seem very
>>> nice as we would be pretending to have a normal MAC address (for
>>> networking) in this SAN device. The networking MAC address is in a
>>> different PCI function.
>>
>> I certainly would prefer if you took that approach. At least in that
>> way the addressing of the netdev objects would appear more consistent.
>>
> Ok. To be more complete, I think we need to add a flag or something to
> such a netdev to indicate that it is a SAN device only. What's your
> opinion on that?
Michael, how do you determine a L2 packet is a SAN type? Do you have
ACLs in the FW/hardware to prevent other types of L2 traffic from being
sent? I guess I'm asking what makes it a SAN only device.
.John
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: David Miller @ 2012-11-14 1:58 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1352857850.6276.71.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 13 Nov 2012 17:50:50 -0800
> On Tue, 2012-11-13 at 20:24 -0500, David Miller wrote:
>> From: "Michael Chan" <mchan@broadcom.com>
>> Date: Tue, 13 Nov 2012 15:40:29 -0800
>>
>> > I suppose we can just put the SAN MAC into the real netdev->dev_addr so
>> > that the VLAN will automatically get it. But this doesn't seem very
>> > nice as we would be pretending to have a normal MAC address (for
>> > networking) in this SAN device. The networking MAC address is in a
>> > different PCI function.
>>
>> I certainly would prefer if you took that approach. At least in that
>> way the addressing of the netdev objects would appear more consistent.
>>
> Ok. To be more complete, I think we need to add a flag or something to
> such a netdev to indicate that it is a SAN device only. What's your
> opinion on that?
Yes, that would describe the limitation you mentioned. Maybe
add a new netdev->priv_flags for this.
^ permalink raw reply
* Re: [RFC PATCH 01/13] net: Add generic packet offload infrastructure.
From: Eric Dumazet @ 2012-11-14 2:24 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, davem
In-Reply-To: <1352856254-29667-2-git-send-email-vyasevic@redhat.com>
On Tue, 2012-11-13 at 20:24 -0500, Vlad Yasevich wrote:
> Create a new data structure to contain the GRO/GSO callbacks and add
> a new registration mechanism.
>
> Singed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> include/linux/netdevice.h | 15 ++++++++
> net/core/dev.c | 80 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 95 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index f8eda02..d15af51 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1511,6 +1511,18 @@ struct packet_type {
> struct list_head list;
> };
>
> +struct packet_offload {
> + __be16 type; /* This is really htons(ether_type). */
> + struct net_device *dev; /* NULL is wildcarded here */
Shouldnt this dev pointer be removed at some point in the patch serie ?
> + struct sk_buff *(*gso_segment)(struct sk_buff *skb,
> + netdev_features_t features);
> + int (*gso_send_check)(struct sk_buff *skb);
> + struct sk_buff **(*gro_receive)(struct sk_buff **head,
> + struct sk_buff *skb);
> + int (*gro_complete)(struct sk_buff *skb);
> + struct list_head list;
> +};
> +
> #include <linux/notifier.h>
>
^ permalink raw reply
* Re: [RFC PATCH 00/13] Always build GSO/GRO functionality into the kernel
From: Eric Dumazet @ 2012-11-14 2:25 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, davem
In-Reply-To: <1352856254-29667-1-git-send-email-vyasevic@redhat.com>
On Tue, 2012-11-13 at 20:24 -0500, Vlad Yasevich wrote:
> This patch series is a revision suggested by Eric to solve the problem where
> a host without IPv6 support drops GSO frames from the guest.
>
> The problem is that GSO/GRO support is per protocol, and when said protocol
> is not loaded or is disabled, packets attempting to go through GSO/GRO code paths
> are dropped. This causes retransmissions and a two orders of magnitude drop in
> performance.
>
> Prior attempt to solve the problem simply enabled enough GSO/GRO functionality
> for IPv6 protocol when IPv6 was diabled. This did not solve the problem when
> the protocol was not build in or was blacklisted.
> To solve the problem, it was suggested that we separate GSO/GRO callback
> registration from packet processing registrations. That way
> GSO/GRO callbacks can be built into the kernel and always be there.
> This patch series attempts to do just that.
> * Patches 1 and 2 split the GSO/GRO handlers from packet_type and convert
> to the new structure.
> * Patches 3, 4 and 5 do the same thing for net_protocol structure.
> * The rest of the patches try to incrementally move the IPv6 GSO/GRO
> code out of the module and into the static kernel build. Some IPv6
> helper functions also had to move as well.
>
> I am currently testing the patches, but if folks could look this over
> and send me any comments, I'd appreciate it.
Seems very nice !
I am just wondering if GSO/GRO is fully enabled at every step ?
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: Michael Chan @ 2012-11-14 2:41 UTC (permalink / raw)
To: John Fastabend, eilong, ariele; +Cc: David Miller, netdev
In-Reply-To: <50A2FAB8.8010803@intel.com>
On Tue, 2012-11-13 at 17:58 -0800, John Fastabend wrote:
> On 11/13/2012 5:50 PM, Michael Chan wrote:
> > On Tue, 2012-11-13 at 20:24 -0500, David Miller wrote:
> >> From: "Michael Chan" <mchan@broadcom.com>
> >> Date: Tue, 13 Nov 2012 15:40:29 -0800
> >>
> >>> I suppose we can just put the SAN MAC into the real netdev->dev_addr so
> >>> that the VLAN will automatically get it. But this doesn't seem very
> >>> nice as we would be pretending to have a normal MAC address (for
> >>> networking) in this SAN device. The networking MAC address is in a
> >>> different PCI function.
> >>
> >> I certainly would prefer if you took that approach. At least in that
> >> way the addressing of the netdev objects would appear more consistent.
> >>
> > Ok. To be more complete, I think we need to add a flag or something to
> > such a netdev to indicate that it is a SAN device only. What's your
> > opinion on that?
>
> Michael, how do you determine a L2 packet is a SAN type? Do you have
> ACLs in the FW/hardware to prevent other types of L2 traffic from being
> sent? I guess I'm asking what makes it a SAN only device.
>
Adding Eilon and Ariel from the bnx2x team to help answer the question.
I think we use ndo_select_queue() to put all FCoE related packets onto
the proper ring that is programmed with the proper DCB parameters.
Packets to the other rings will be dropped on such a device.
That's why a flag will be useful so that tools will know its limitation.
>
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-11-14 2:47 UTC (permalink / raw)
To: Dave, Tushar N
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA89133487884@ORSMSX102.amr.corp.intel.com>
On 11/09/12 04:35, Dave, Tushar N wrote:
> All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang.
> Can you double check this?
Hi Tushar,
Checked with hardware vendor and they said no way to modify the max payload size
from BIOS, can I modify it from driver side?
Thanks,
Joe
^ permalink raw reply
* Re: 82571EB: Detected Hardware Unit Hang
From: Li Yu @ 2012-11-14 3:37 UTC (permalink / raw)
To: Dave, Tushar N
Cc: Joe Jin, e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA89133487884@ORSMSX102.amr.corp.intel.com>
于 2012年11月09日 04:35, Dave, Tushar N 写道:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of Joe Jin
>> Sent: Wednesday, November 07, 2012 10:25 PM
>> To: e1000-devel@lists.sf.net
>> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Mary Mcgrath
>> Subject: 82571EB: Detected Hardware Unit Hang
>>
>> Hi list,
>>
>> IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant DL360
>> G6, and have to reboot the server to recover:
>>
>> e1000e 0000:06:00.1: eth3: Detected Hardware Unit Hang:
>> TDH <1a>
>> TDT <1a>
>> next_to_use <1a>
>> next_to_clean <18>
>> buffer_info[next_to_clean]:
>> time_stamp <10047a74e>
>> next_to_watch <18>
>> jiffies <10047a88c>
>> next_to_watch.status <1>
>> MAC Status <80383>
>> PHY Status <792d>
>> PHY 1000BASE-T Status <3800>
>> PHY Extended Status <3000>
>> PCI Status <10>
>>
>> With newer kernel 2.0.0.1 the issue still reproducible.
>>
>> Device info:
>> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>> Controller (Copper) (rev 06)
>> 06:00.1 0200: 8086:10bc (rev 06)
>>
>> I compared lspci output before and after the issue, different as below:
>> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>> Controller (Copper) (rev 06)
>> Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port
>> Gigabit Server Adapter
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>> Stepping- SERR- FastB2B- DisINTx-
>> - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> +<TAbort- <MAbort- >SERR- <PERR- INTx+
>
> Are you sure this is not similar issue as before that you reported.
> i.e.
> On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
>> I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
>> doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
>> just copy a big file (>500M) from another server will hit it at once.
>
> All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang.
> Can you double check this?
>
We also found such hang problem on 82599EB (ixgbe driver) in RHEL6.3
kernel, we ever tried to upgrade to latest version (3.8.21 or 3.10.17),
but it still happens.
Is it probably also due to wrong "max payload size" set in BIOS?
Thanks
Yu
> -Tushar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-11-14 3:43 UTC (permalink / raw)
To: Li Yu
Cc: Joe Jin, e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <50A311E9.9030702@gmail.com>
>-----Original Message-----
>From: Li Yu [mailto:raise.sail@gmail.com]
>Sent: Tuesday, November 13, 2012 7:37 PM
>To: Dave, Tushar N
>Cc: Joe Jin; e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org; Mary Mcgrath
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>于 2012年11月09日 04:35, Dave, Tushar N 写道:
>>> -----Original Message-----
>>> From: netdev-owner@vger.kernel.org
>>> [mailto:netdev-owner@vger.kernel.org]
>>> On Behalf Of Joe Jin
>>> Sent: Wednesday, November 07, 2012 10:25 PM
>>> To: e1000-devel@lists.sf.net
>>> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Mary
>>> Mcgrath
>>> Subject: 82571EB: Detected Hardware Unit Hang
>>>
>>> Hi list,
>>>
>>> IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant
>>> DL360 G6, and have to reboot the server to recover:
>>>
>>> e1000e 0000:06:00.1: eth3: Detected Hardware Unit Hang:
>>> TDH <1a>
>>> TDT <1a>
>>> next_to_use <1a>
>>> next_to_clean <18>
>>> buffer_info[next_to_clean]:
>>> time_stamp <10047a74e>
>>> next_to_watch <18>
>>> jiffies <10047a88c>
>>> next_to_watch.status <1>
>>> MAC Status <80383>
>>> PHY Status <792d>
>>> PHY 1000BASE-T Status <3800>
>>> PHY Extended Status <3000>
>>> PCI Status <10>
>>>
>>> With newer kernel 2.0.0.1 the issue still reproducible.
>>>
>>> Device info:
>>> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>> Ethernet Controller (Copper) (rev 06)
>>> 06:00.1 0200: 8086:10bc (rev 06)
>>>
>>> I compared lspci output before and after the issue, different as below:
>>> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>> Ethernet Controller (Copper) (rev 06)
>>> Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port
>>> Gigabit Server Adapter
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>>> Stepping- SERR- FastB2B- DisINTx-
>>> - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> +<TAbort- <MAbort- >SERR- <PERR- INTx+
>>
>> Are you sure this is not similar issue as before that you reported.
>> i.e.
>> On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
>>> I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
>>> doing scp test. this issue is easy do reproduced on SUN FIRE X2270
>>> M2, just copy a big file (>500M) from another server will hit it at
>once.
>>
>> All devices in path from root complex to 82571, should have *same* max
>payload size otherwise it can cause hang.
>> Can you double check this?
>>
>
>We also found such hang problem on 82599EB (ixgbe driver) in RHEL6.3
>kernel, we ever tried to upgrade to latest version (3.8.21 or 3.10.17),
>but it still happens.
>
>Is it probably also due to wrong "max payload size" set in BIOS?
>
It could be or could not be. I would suggest please create another thread with that issue as these two devices are significantly different.
-Tushar
^ permalink raw reply
* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-11-14 3:45 UTC (permalink / raw)
To: Joe Jin
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mary Mcgrath
In-Reply-To: <50A30656.6090508@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Tuesday, November 13, 2012 6:48 PM
>To: Dave, Tushar N
>Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org; Mary Mcgrath
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 11/09/12 04:35, Dave, Tushar N wrote:
>> All devices in path from root complex to 82571, should have *same* max
>payload size otherwise it can cause hang.
>> Can you double check this?
>
>Hi Tushar,
>
>Checked with hardware vendor and they said no way to modify the max
>payload size from BIOS, can I modify it from driver side?
If you want to change value for 82571 device you can do it from eeprom but for other upstream devices I am not sure. I will check with my team.
-Tushar
^ permalink raw reply
* [PATCH] drivers/net: fix tasklet misuse issue
From: Xiaotian Feng @ 2012-11-14 5:47 UTC (permalink / raw)
To: davem; +Cc: Xiaotian Feng, Xiaotian Feng, netdev, linux-kernel
In commit 175c0dff, drivers uses tasklet_kill to avoid put disabled tasklet
on the tasklet vec. But some of the drivers uses tasklet_init & tasklet_disable
in the driver init code, then tasklet_enable when it is opened. This makes
tasklet_enable on a killed tasklet and make ksoftirqd crazy then. Normally,
drivers should use tasklet_init/tasklet_kill on device open/remove, and use
tasklet_disable/tasklet_enable on device suspend/resume.
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/jme.c | 28 ++++++---------------
drivers/net/ethernet/micrel/ksz884x.c | 16 +++---------
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 12 ++++-----
3 files changed, 18 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 92317e9..c0314c1 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -1860,10 +1860,14 @@ jme_open(struct net_device *netdev)
jme_clear_pm(jme);
JME_NAPI_ENABLE(jme);
- tasklet_enable(&jme->linkch_task);
- tasklet_enable(&jme->txclean_task);
- tasklet_hi_enable(&jme->rxclean_task);
- tasklet_hi_enable(&jme->rxempty_task);
+ tasklet_init(&jme->linkch_task, jme_link_change_tasklet,
+ (unsigned long) jme);
+ tasklet_init(&jme->txclean_task, jme_tx_clean_tasklet,
+ (unsigned long) jme);
+ tasklet_init(&jme->rxclean_task, jme_rx_clean_tasklet,
+ (unsigned long) jme);
+ tasklet_init(&jme->rxempty_task, jme_rx_empty_tasklet,
+ (unsigned long) jme);
rc = jme_request_irq(jme);
if (rc)
@@ -3079,22 +3083,6 @@ jme_init_one(struct pci_dev *pdev,
tasklet_init(&jme->pcc_task,
jme_pcc_tasklet,
(unsigned long) jme);
- tasklet_init(&jme->linkch_task,
- jme_link_change_tasklet,
- (unsigned long) jme);
- tasklet_init(&jme->txclean_task,
- jme_tx_clean_tasklet,
- (unsigned long) jme);
- tasklet_init(&jme->rxclean_task,
- jme_rx_clean_tasklet,
- (unsigned long) jme);
- tasklet_init(&jme->rxempty_task,
- jme_rx_empty_tasklet,
- (unsigned long) jme);
- tasklet_disable_nosync(&jme->linkch_task);
- tasklet_disable_nosync(&jme->txclean_task);
- tasklet_disable_nosync(&jme->rxclean_task);
- tasklet_disable_nosync(&jme->rxempty_task);
jme->dpi.cur = PCC_P1;
jme->reg_ghc = 0;
diff --git a/drivers/net/ethernet/micrel/ksz884x.c b/drivers/net/ethernet/micrel/ksz884x.c
index e558edd..b66b285 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -5459,8 +5459,10 @@ static int prepare_hardware(struct net_device *dev)
rc = request_irq(dev->irq, netdev_intr, IRQF_SHARED, dev->name, dev);
if (rc)
return rc;
- tasklet_enable(&hw_priv->rx_tasklet);
- tasklet_enable(&hw_priv->tx_tasklet);
+ tasklet_init(&hw_priv->rx_tasklet, rx_proc_task,
+ (unsigned long) hw_priv);
+ tasklet_init(&hw_priv->tx_tasklet, tx_proc_task,
+ (unsigned long) hw_priv);
hw->promiscuous = 0;
hw->all_multi = 0;
@@ -7033,16 +7035,6 @@ static int __devinit pcidev_init(struct pci_dev *pdev,
spin_lock_init(&hw_priv->hwlock);
mutex_init(&hw_priv->lock);
- /* tasklet is enabled. */
- tasklet_init(&hw_priv->rx_tasklet, rx_proc_task,
- (unsigned long) hw_priv);
- tasklet_init(&hw_priv->tx_tasklet, tx_proc_task,
- (unsigned long) hw_priv);
-
- /* tasklet_enable will decrement the atomic counter. */
- tasklet_disable(&hw_priv->rx_tasklet);
- tasklet_disable(&hw_priv->tx_tasklet);
-
for (i = 0; i < TOTAL_PORT_NUM; i++)
init_waitqueue_head(&hw_priv->counter[i].counter);
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 1d04754..7740f4b 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -942,6 +942,10 @@ static int axienet_open(struct net_device *ndev)
phy_start(lp->phy_dev);
}
+ /* Enable tasklets for Axi DMA error handling */
+ tasklet_init(&lp->dma_err_tasklet, axienet_dma_err_handler,
+ (unsigned long) lp);
+
/* Enable interrupts for Axi DMA Tx */
ret = request_irq(lp->tx_irq, axienet_tx_irq, 0, ndev->name, ndev);
if (ret)
@@ -950,8 +954,7 @@ static int axienet_open(struct net_device *ndev)
ret = request_irq(lp->rx_irq, axienet_rx_irq, 0, ndev->name, ndev);
if (ret)
goto err_rx_irq;
- /* Enable tasklets for Axi DMA error handling */
- tasklet_enable(&lp->dma_err_tasklet);
+
return 0;
err_rx_irq:
@@ -960,6 +963,7 @@ err_tx_irq:
if (lp->phy_dev)
phy_disconnect(lp->phy_dev);
lp->phy_dev = NULL;
+ tasklet_kill(&lp->dma_err_tasklet);
dev_err(lp->dev, "request_irq() failed\n");
return ret;
}
@@ -1613,10 +1617,6 @@ static int __devinit axienet_of_probe(struct platform_device *op)
goto err_iounmap_2;
}
- tasklet_init(&lp->dma_err_tasklet, axienet_dma_err_handler,
- (unsigned long) lp);
- tasklet_disable(&lp->dma_err_tasklet);
-
return 0;
err_iounmap_2:
--
1.7.9.6 (Apple Git-31.1)
^ permalink raw reply related
* Re: [3.0.y, 3.2.y, 3.4.y] Re: [PATCH 2/2] [sky2] Fix for interrupt handler
From: Ben Hutchings @ 2012-11-14 5:49 UTC (permalink / raw)
To: David Miller; +Cc: jrnieder, jdg, mlindner, shemminger, netdev, stable
In-Reply-To: <20121113.031446.1481052044099452015.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
On Tue, 2012-11-13 at 03:14 -0500, David Miller wrote:
> From: Jonathan Nieder <jrnieder@gmail.com>
> Date: Sat, 3 Nov 2012 03:04:48 -0700
>
> > On October 25, Jonathan Nieder wrote:
> >> Mirko Lindner wrote:
> >
> >>> Re-enable interrupts if it is not our interrupt
> >>>
> >>> Signed-off-by: Mirko Lindner <mlindner@marvell.com>
> > [...]
> >> Tested-by: Julian Gilbey <jdg@debian.org> # 3.2.y, Inspiron 1545
> >
> > Ping. Dave, is
> >
> > d663d181b9e9 sky2: Fix for interrupt handler
> >
> > a candidate for inclusion in 3.0-, 3.2-, and 3.4-stable? (It was
> > applied upstream during the 3.6 merge window.) I don't see it in
> > the list at [2].
>
> This looks fine.
Queued up for 3.2, thanks all.
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH V3] wanrouter: Remove it and the drivers that depend on it
From: Paul Gortmaker @ 2012-11-14 6:08 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev
In-Reply-To: <20121113.204437.197646115673556624.davem@davemloft.net>
[Re: [PATCH V3] wanrouter: Remove it and the drivers that depend on it] On 13/11/2012 (Tue 20:44) David Miller wrote:
>
> Paul, you can't have HTML content to the list and one of your MIME
> sections was HTML, so it was rejected by vger's filters.
>
> Please repost with the HTML stuff removed.
Ah crap. I'd replied via gmail ; today and occasionally in the past as
a convenient short cut when not reading netdev with a "normal" MUA. And
this is not the 1st time gmail has randomly decided to be "helpful" by
mangling plain text like this. Well, I'll be having no more of that BS.
Sorry about that; I know you don't need the extra stupidity to deal
with, esp. at this point in time. Original plain text follows, courtesy
of reliable 1990's MUA technology -- the pull details remain unchanged.
Paul.
--
On Tue, Nov 13, 2012 at 6:22 PM, David Miller <davem@davemloft.net> wrote:
>From: Joe Perches <joe@perches.com>
>Date: Tue, 13 Nov 2012 14:36:04 -0800
>> Remove wanrouter as it's obsolete and has not been updated
>> by sangoma since 2.4.3 or so and it's not used anymore.
>>
>> Remove obsolete cyclomx drivers.
>> Update files that include now deleted wanrouter bits.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>This breaks the build.
>drivers/isdn/i4l/isdn_x25iface.c:33:18: error: field ‘state’ has incomplete type
>drivers/isdn/i4l/isdn_x25iface.c: In function ‘isdn_x25iface_proto_new’:
>drivers/isdn/i4l/isdn_x25iface.c:89:16: error: ‘WAN_UNCONFIGURED’ undeclared (first use in this function)
[...]
I'd hate to see a garbage collection miss out from integration due to
wider testing, so I've taken Joe's commit, put it on today's net-next
and made the following changes:
-keep magic number references but mark them obsolete (nobody asked for
this, but it made sense to me).
-keep the wanrouter.h (uapi and kernel-centric one) files, but with
only the X.25 bits that caused build failures. I have trimmed the enum
to just the bits that were used. Obvious build failures like davem
reported aside, I was concerned that userspace might reference the
headers (got caught on this for my token-ring deletion). I did not find
any userspace uses, but it was packaged with most distro's libc header
content, so who knows? As I did run into this with the token ring
delete, so this is the safer route here -- i.e. leaving a skeleton
header.
I don't want to spam everyone with another giant patch, so note that a
diff from Joe's original and my amendment is shown below (warning - cut
and paste damaged ; not that anyone sane should, but don't try and apply
this delta; it is for review purposes only -- and all lines with "+" are
just restoration of what lines were already there).
For the folks well adapted to git already, I've pushed an equivalent
branch that I have done the build testing of an x86_64 allyesconfig and
allmodconfig, and they compile OK. This is based on the net-next of
today:
The following changes since commit bf0098f22ca7b59e8844ac6882bbae230d34b98d:
ARM: net: bpf_jit_32: add VLAN instructions for BPF JIT (2012-11-13 18:21:10 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git wanrouter-delete
for you to fetch changes up to 148233ec812733b88ad4d341a07e23229ed02810:
wanrouter: Remove it and the drivers that depend on it (2012-11-13 19:53:15 -0500)
----------------------------------------------------------------
Joe Perches (1):
wanrouter: Remove it and the drivers that depend on it
Documentation/ioctl/ioctl-number.txt | 2 +-
Documentation/magic-number.txt | 2 +-
Documentation/zh_CN/magic-number.txt | 2 +-
drivers/isdn/i4l/isdn_x25iface.h | 1 -
drivers/net/wan/Kconfig | 54 --
drivers/net/wan/Makefile | 5 -
drivers/net/wan/cycx_drv.c | 569 ------------
drivers/net/wan/cycx_main.c | 346 --------
drivers/net/wan/cycx_x25.c | 1602 ----------------------------------
include/linux/cyclomx.h | 77 --
include/linux/cycx_drv.h | 64 --
include/linux/wanrouter.h | 127 +--
include/uapi/linux/Kbuild | 1 -
include/uapi/linux/wanrouter.h | 443 +---------
net/Kconfig | 1 -
net/Makefile | 1 -
net/socket.c | 1 -
net/wanrouter/Kconfig | 27 -
net/wanrouter/Makefile | 7 -
net/wanrouter/patchlevel | 1 -
net/wanrouter/wanmain.c | 782 -----------------
net/wanrouter/wanproc.c | 380 --------
22 files changed, 11 insertions(+), 4484 deletions(-)
delete mode 100644 drivers/net/wan/cycx_drv.c
delete mode 100644 drivers/net/wan/cycx_main.c
delete mode 100644 drivers/net/wan/cycx_x25.c
delete mode 100644 include/linux/cyclomx.h
delete mode 100644 include/linux/cycx_drv.h
delete mode 100644 net/wanrouter/Kconfig
delete mode 100644 net/wanrouter/Makefile
delete mode 100644 net/wanrouter/patchlevel
delete mode 100644 net/wanrouter/wanmain.c
delete mode 100644 net/wanrouter/wanproc.c
-- below not for application, review only ; delta diff follows --
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 028a034..bb8315a 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -179,6 +179,7 @@ Code Seq#(hex) Include File Comments
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'W' 00-1F linux/watchdog.h conflict!
+'W' 00-1F linux/wanrouter.h conflict! (pre 3.8)
'W' 00-3F sound/asound.h conflict!
'X' all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index 0c39e72..851e447 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@@ -122,6 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
+ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.8]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
index 51b7e15..5ab5271 100644
--- a/Documentation/zh_CN/magic-number.txt
+++ b/Documentation/zh_CN/magic-number.txt
@@ -122,6 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
+ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.8]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
diff --git a/drivers/isdn/i4l/isdn_x25iface.c b/drivers/isdn/i4l/isdn_x25iface.c
index d00c86d..e2d4e58 100644
--- a/drivers/isdn/i4l/isdn_x25iface.c
+++ b/drivers/isdn/i4l/isdn_x25iface.c
@@ -21,6 +21,7 @@
#include <linux/netdevice.h>
#include <linux/concap.h>
#include <linux/slab.h>
+#include <linux/wanrouter.h>
#include <net/x25device.h>
#include "isdn_x25iface.h"
diff --git a/include/linux/wanrouter.h b/include/linux/wanrouter.h
new file mode 100644
index 0000000..8198a63
--- /dev/null
+++ b/include/linux/wanrouter.h
@@ -0,0 +1,10 @@
+/*
+ * wanrouter.h Legacy declarations kept around until X25 is removed
+ */
+
+#ifndef _ROUTER_H
+#define _ROUTER_H
+
+#include <uapi/linux/wanrouter.h>
+
+#endif /* _ROUTER_H */
diff --git a/include/uapi/linux/wanrouter.h b/include/uapi/linux/wanrouter.h
new file mode 100644
index 0000000..498d6c1
--- /dev/null
+++ b/include/uapi/linux/wanrouter.h
@@ -0,0 +1,17 @@
+/*
+ * wanrouter.h Legacy declarations kept around until X25 is removed
+ */
+
+#ifndef _UAPI_ROUTER_H
+#define _UAPI_ROUTER_H
+
+/* 'state' defines */
+enum wan_states
+{
+ WAN_UNCONFIGURED, /* link/channel is not configured */
+ WAN_DISCONNECTED, /* link/channel is disconnected */
+ WAN_CONNECTING, /* connection is in progress */
+ WAN_CONNECTED /* link/channel is operational */
+};
+
+#endif /* _UAPI_ROUTER_H */
^ permalink raw reply related
* Re: [v6 PATCH 1/8] cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header updates).
From: James Bottomley @ 2012-11-14 2:26 UTC (permalink / raw)
To: Naresh Kumar Inna; +Cc: linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1351158621-32222-2-git-send-email-naresh@chelsio.com>
On Thu, 2012-10-25 at 15:20 +0530, Naresh Kumar Inna wrote:
> This patch contains updates to firmware/hardware header files shared
> between csiostor and cxgb4/cxgb4vf, and the resulting changes to the
> cxgb4/cxgb4vf source files.
>
> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 ++--
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 6 ++--
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 20 +++++-----
> drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 1 +
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 36 +++++++++++++++++++-
> drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 41 ++++++++++++++++++++---
> drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 8 ++--
> 7 files changed, 92 insertions(+), 28 deletions(-)
This still doesn't compile:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function ‘adap_init0’:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3932:10: error: ‘struct fw_caps_config_cmd’ has no member named ‘retval_len16’
make[5]: *** [drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o] Error 1
James
^ permalink raw reply
* Re: [RFC PATCH 03/13] net: Add net protocol offload registration infrustructure
From: Nicolas Dichtel @ 2012-11-14 8:22 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, eric.dumazet, davem
In-Reply-To: <1352856254-29667-4-git-send-email-vyasevic@redhat.com>
Le 14/11/2012 02:24, Vlad Yasevich a écrit :
> Create a new data structure for IPv4 protocols that holds GRO/GSO
> callbacks and a new array to track the protocols that register GRO/GSO.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> include/net/protocol.h | 12 ++++++++++++
> net/ipv4/af_inet.c | 12 ++++++++++++
> net/ipv4/protocol.c | 22 +++++++++++++++++++++-
> 3 files changed, 45 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/protocol.h b/include/net/protocol.h
> index 929528c..d8ecb17 100644
> --- a/include/net/protocol.h
> +++ b/include/net/protocol.h
> @@ -77,6 +77,15 @@ struct inet6_protocol {
> #define INET6_PROTO_GSO_EXTHDR 0x4
> #endif
>
> +struct net_offload {
> + int (*gso_send_check)(struct sk_buff *skb);
> + struct sk_buff *(*gso_segment)(struct sk_buff *skb,
> + netdev_features_t features);
> + struct sk_buff **(*gro_receive)(struct sk_buff **head,
> + struct sk_buff *skb);
> + int (*gro_complete)(struct sk_buff *skb);
> +};
> +
> /* This is used to register socket interfaces for IP protocols. */
> struct inet_protosw {
> struct list_head list;
> @@ -96,6 +105,7 @@ struct inet_protosw {
> #define INET_PROTOSW_ICSK 0x04 /* Is this an inet_connection_sock? */
>
> extern const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS];
> +extern const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS];
>
> #if IS_ENABLED(CONFIG_IPV6)
> extern const struct inet6_protocol __rcu *inet6_protos[MAX_INET_PROTOS];
> @@ -103,6 +113,8 @@ extern const struct inet6_protocol __rcu *inet6_protos[MAX_INET_PROTOS];
>
> extern int inet_add_protocol(const struct net_protocol *prot, unsigned char num);
> extern int inet_del_protocol(const struct net_protocol *prot, unsigned char num);
> +extern int inet_add_offload(const struct net_offload *prot, unsigned char num);
> +extern int inet_del_offload(const struct net_offload *prot, unsigned char num);
> extern void inet_register_protosw(struct inet_protosw *p);
> extern void inet_unregister_protosw(struct inet_protosw *p);
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 4c99c5f..3918d86 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1566,6 +1566,13 @@ static const struct net_protocol tcp_protocol = {
> .netns_ok = 1,
> };
>
> +static const struct net_offload tcp_offload = {
> + .gso_send_check = tcp_v4_gso_send_check,
> + .gso_segment = tcp_tso_segment,
> + .gro_receive = tcp4_gro_receive,
> + .gro_complete = tcp4_gro_complete,
> +};
> +
> static const struct net_protocol udp_protocol = {
> .handler = udp_rcv,
> .err_handler = udp_err,
> @@ -1575,6 +1582,11 @@ static const struct net_protocol udp_protocol = {
> .netns_ok = 1,
> };
>
> +static const struct net_offload udp_offload = {
> + .gso_send_check = udp4_ufo_send_check,
> + .gso_segment = udp4_ufo_fragment,
> +};
> +
> static const struct net_protocol icmp_protocol = {
> .handler = icmp_rcv,
> .err_handler = ping_err,
> diff --git a/net/ipv4/protocol.c b/net/ipv4/protocol.c
> index 8918eff..1278db8 100644
> --- a/net/ipv4/protocol.c
> +++ b/net/ipv4/protocol.c
> @@ -29,6 +29,7 @@
> #include <net/protocol.h>
>
> const struct net_protocol __rcu *inet_protos[MAX_INET_PROTOS] __read_mostly;
> +const struct net_offload __rcu *inet_offloads[MAX_INET_PROTOS] __read_mostly;
>
> /*
> * Add a protocol handler to the hash tables
> @@ -41,6 +42,13 @@ int inet_add_protocol(const struct net_protocol *prot, unsigned char protocol)
> }
> EXPORT_SYMBOL(inet_add_protocol);
>
> +int inet_add_offload(const struct net_offload *prot, unsigned char protocol)
> +{
> + return !cmpxchg((const struct net_offload **)&inet_offloads[protocol],
> + NULL, prot) ? 0 : -1;
> +}
> +EXPORT_SYMBOL(inet_add_offload);
> +
> /*
> * Remove a protocol from the hash tables.
> */
> @@ -56,4 +64,16 @@ int inet_del_protocol(const struct net_protocol *prot, unsigned char protocol)
>
> return ret;
> }
> -EXPORT_SYMBOL(inet_del_protocol);
This line should probably not be removed ;-)
^ permalink raw reply
* IPv6 bonding support?
From: Roy Sigurd Karlsbakk @ 2012-11-14 8:26 UTC (permalink / raw)
To: netdev
Hi all
I've setup bonding on a few machines here. They're all blades in a Dell blade chassis, so they're both connected to the four internal switches (2 gigE, 2 10GigE). Using 10GigE only, I've setup bonding in active-backup mode with the ARP driver. While this works well, we're planning ahead for running IPv6 only.
Does anyone kow if something's in the works to allow redundant links in an IPv6-only setup?
Please cc: to me as I'm not on the list
Vennlige hilsener / Best regards
roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy@karlsbakk.net
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
^ permalink raw reply
* Re: [PATCH v5 3/9] net: xfrm: use __this_cpu_read per-cpu helper
From: Steffen Klassert @ 2012-11-14 8:43 UTC (permalink / raw)
To: Shan Wei
Cc: Christoph Lameter, David Miller, NetDev, Herbert Xu,
Kernel-Maillist
In-Reply-To: <50A23EB0.1060808@gmail.com>
On Tue, Nov 13, 2012 at 08:36:00PM +0800, Shan Wei wrote:
> Steffen Klassert said, at 2012/11/13 18:48:
> >
> > Ok, so please add a commit message to describe your changes.
> >
> > Thanks.
> >
>
> [PATCH v5] net: xfrm: use __this_cpu_read per-cpu helper
>
> this_cpu_ptr/this_cpu_read is faster than per_cpu_ptr(p, smp_processor_id())
> and can reduce memory accesses.
> The latter helper needs to find the offset for current cpu,
> and needs more assembler instructions which objdump shows in following.
>
> this_cpu_ptr relocates and address. this_cpu_read() relocates the address
> and performs the fetch. this_cpu_read() saves you more instructions
> since it can do the relocation and the fetch in one instruction.
>
> per_cpu_ptr(p, smp_processor_id())：
> 1e: 65 8b 04 25 00 00 00 00 mov %gs:0x0,%eax
> 26: 48 98 cltq
> 28: 31 f6 xor %esi,%esi
> 2a: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
> 31: 48 8b 04 c5 00 00 00 00 mov 0x0(,%rax,8),%rax
> 39: c7 44 10 04 14 00 00 00 movl $0x14,0x4(%rax,%rdx,1)
>
> this_cpu_ptr(p)
> 1e: 65 48 03 14 25 00 00 00 00 add %gs:0x0,%rdx
> 27: 31 f6 xor %esi,%esi
> 29: c7 42 04 14 00 00 00 movl $0x14,0x4(%rdx)
> 30: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
>
> Signed-off-by: Shan Wei <davidshan@tencent.com>
Applied to ipsec-next, thanks!
^ permalink raw reply
* Re: [REGRESSION] r8169: jumbo fixes caused jumbo regressions!
From: Kirill Smelkov @ 2012-11-14 9:25 UTC (permalink / raw)
To: Francois Romieu
Cc: Realtek linux nic maintainers, Hayes Wang, David S. Miller,
Greg Kroah-Hartman, netdev
In-Reply-To: <20121113223512.GA29342@electric-eye.fr.zoreil.com>
On Tue, Nov 13, 2012 at 11:35:12PM +0100, Francois Romieu wrote:
> Kirill Smelkov <kirr@mns.spb.ru> :
> [...]
> > My test is to stream raw video from 8 PAL cameras to net - 4 for 720x576@25 and
> > 4 for 360x288@25 which for YUYV format occupies ~ 860 Mbps of bandwidth. The
> > program to transmit/receive video is here: http://repo.or.cz/w/rawv.git
>
> $ git clone http://repo.or.cz/w/rawv.git
> Cloning into 'rawv'...
> fatal: http://repo.or.cz/w/rawv.git/info/refs not valid: is this a git repository?
That's a gitweb view. The actual git repo is here:
git://repo.or.cz/rawv.git
sorry for confusion.
( if you'll want to test with vivi on a slow system, you'll need my
patches, currently staging in media-tree patchwork, or available here:
git://repo.or.cz/linux-2.6/kirr.git vivi-speedup-and-fps.over-net-next )
> [...]
> > (by the way, on atom system, without tx csum offload, half of cpu time
> > is spent only to calculate checksums...)
>
> :o(
yes, that large. In top, my workload is
%sy %id %si
default driver load ~25 ~45 ~27
(ethtool -k shows
tx-checksumming: off)
after ~8 ~81 ~11
`ethtool -K eth0 tx on`
that's why the issue is important.
> > Now I wonder, where that 6K limit came from and why they say it is now
> > not possible to use jumbos together with tx csum offload ?
>
> Here is an excerpt from a mail where Hayes explained the rules of
> engagement back in may 2011 (John Lumby and Chris Friesen were Cced then):
Can't find that mail in gmane netdev archive and on google, to restore
full context. Was that in private?
> ! The Max tx sizes for 8168 series are as following:
> !
> ! 8168B is 4K bytes.
> ! 8168C and 8168CP are 6K bytes.
> ! 8168D and later are 9K bytes.
> !
> ! Note that these sizes all include head size. That is, the mtu must less than
> ! these values.
> ! You have to enable Jumbo frame feature when the tx size is large, otherwise the
> ! packet would not be sent. Because the hw doesn't provide the threshold, the
> ! checking for MTU > 1500 is just for convenience for sw.
This part is clear.
> ! The TSO couldn't work with some feature which need to disable hw checksum, such
> ! as Jumbo frame. The hw checksum have to be disabled in certain situations, so
> ! the TSO feature should be checked in these situations, too.
I don't enable TSO nor I need it. The text indirectly says that hw
checksum should be disabled when jumbo frames are used.
~~~~
Hayes, Realtek linux nic maintainers,
could you please confirm that for all 8168C and 8168CP jumbo_max is
6K and that when jumbos are used, tx checksumming should be off?
If so, how come my two chips work stable with ~7K jumbos and tx checksum
offload on (tested this night again for ~16 hours without any problem).
thanks beforehand.
> > Is my testing enough to justify raising the limits and allowing tx offload ?
>
> I don't oppose knobs to go off-limits but I'll need some rather good reason
> before changing the manufacturer's suggested defaults.
Thanks. Let's see what Realtek people say.
Kirill
^ permalink raw reply
* Re: [PATCH net-next] add DOVE extensions for VXLAN
From: David Stevens @ 2012-11-14 10:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20121113144148.66a86bc7@nehalam.linuxnetplumber.net>
Stephen Hemminger <shemminger@vyatta.com> wrote on 11/13/2012 05:41:48 PM:
> > Someone who doesn't want all of them shouldn't use this
feature.
> > If we're dropping the "dove" flag in favor of individual flags for
each
> > feature, then I could make this into "l2miss" and "l3miss" flags and
> > they should default off, of course.
> >
> > +-DLS
>
> Maybe a OVS style "here is the homeless packet" message is needed.
> That would allow for controller in user space to populate table
> on as needed basis.
The netlink notifications are sending just the link information
and one of a MAC address or an IP address, depending on the sort of
miss we have. Sending the whole packet to user space would add up
to 64K of user packet data that is completely useless to us.
Rate-limiting based on destination means keeping state of
some sort, which means an attacker can present you with new state
to keep on every packet (like sequentially sending to all possible
Internet addresses).
I think a DoS attack from a hosted VM is no different than
any other, unintentional, disproportionate use of resources by a VM
and is ultimately a matter for the host admin.
The netlink notifications include minimal information for
filling the forwarding table on demand and even the ordinary VXLAN
way of sending all the user data via multicast will result in
replication of packet data (up to 64K) to send to multiple destinations,
all
but one of which will ultimately drop it in the unicast dst case. This,
until a valid unicast forwarding table entry is in place.
I think, by comparison, a (smaller) netlink message locally
on every miss is fairly lightweight. We could keep state of what
destinations we've done notifications on, but then we have to age
these and this does nothing for DoS attacks which only have to send to
lots of different destinations to overflow our state table.
The code I sent only turns on notifications at all when the
"dove" flag is set and we can split this into separate flags to allow
finer control. But I don't think sending multiple copies of whole
packets remotely or a single copy of the whole packet locally is
better than sending just the address info locally for unknown
destinations.
+-DLS
^ permalink raw reply
* [PATCH] net/smsc911x: Fix ready check in cases where WORD_SWAP is needed
From: Kamlakant Patel @ 2012-11-14 11:41 UTC (permalink / raw)
To: netdev; +Cc: steve, davem, linus.walleij, robert.marklund, Kamlakant Patel
The chip ready check added by the commit 3ac3546e [Always wait for
the chip to be ready] does not work when the register read/write
is word swapped. This check has been added before the WORD_SWAP
register is programmed, so we need to check for swapped register
value as well.
Bit 16 is marked as RESERVED in SMSC datasheet, Steve Glendinning
<steve@shawell.net> checked with SMSC and wrote:
The chip architects have concluded we should be reading PMT_CTRL
until we see any of bits 0, 8, 16 or 24 set. Then we should read
BYTE_TEST to check the byte order is correct (as we already do).
The rationale behind this is that some of the chip variants have
word order swapping features too, so the READY bit could actually
be in any of the 4 possible locations. The architects have confirmed
that if any of these 4 positions is set the chip is ready. The other
3 locations will either never be set or can only go high after READY
does (so also indicate the device is ready).
This change will check for the READY bit at the 16th position. We do
not check the other two cases (bit 8 and 24) since the driver does not
support byte-swapped register read/write.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
---
drivers/net/ethernet/smsc/smsc911x.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 62d1baf..c53c0f4 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2110,7 +2110,7 @@ static void __devinit smsc911x_read_mac_address(struct net_device *dev)
static int __devinit smsc911x_init(struct net_device *dev)
{
struct smsc911x_data *pdata = netdev_priv(dev);
- unsigned int byte_test;
+ unsigned int byte_test, mask;
unsigned int to = 100;
SMSC_TRACE(pdata, probe, "Driver Parameters:");
@@ -2130,9 +2130,22 @@ static int __devinit smsc911x_init(struct net_device *dev)
/*
* poll the READY bit in PMT_CTRL. Any other access to the device is
* forbidden while this bit isn't set. Try for 100ms
+ *
+ * Note that this test is done before the WORD_SWAP register is
+ * programmed. So in some configurations the READY bit is at 16 before
+ * WORD_SWAP is written to. This issue is worked around by waiting
+ * until either bit 0 or bit 16 gets set in PMT_CTRL.
+ *
+ * SMSC has confirmed that checking bit 16 (marked as reserved in
+ * the datasheet) is fine since these bits "will either never be set
+ * or can only go high after READY does (so also indicate the device
+ * is ready)".
*/
- while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
+
+ mask = PMT_CTRL_READY_ | swahw32(PMT_CTRL_READY_);
+ while (!(smsc911x_reg_read(pdata, PMT_CTRL) & mask) && --to)
udelay(1000);
+
if (to == 0) {
pr_err("Device not READY in 100ms aborting\n");
return -ENODEV;
--
1.7.6
^ permalink raw reply related
* RE: [PATCH 1/3] net: Add support for hardware-offloaded encapsulation
From: Dmitry Kravkov @ 2012-11-14 12:23 UTC (permalink / raw)
To: Joseph Gasparakis, davem@davemloft.net, shemminger@vyatta.com,
chrisw@sous-sol.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter P Waskiewicz Jr
In-Reply-To: <1352427483-4380-2-git-send-email-joseph.gasparakis@intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Joseph Gasparakis
> Sent: Friday, November 09, 2012 4:18 AM
> To: davem@davemloft.net; shemminger@vyatta.com; chrisw@sous-sol.org
> Cc: Joseph Gasparakis; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Peter P Waskiewicz Jr
> Subject: [PATCH 1/3] net: Add support for hardware-offloaded encapsulation
>
> This patch adds support in the kernel for offloading in the NIC Tx and Rx
> checksumming for encapsulated packets (such as VXLAN and IP GRE)
>
> Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
[D.K.]
> NETIF_F_HW_CSUM_BIT, /* Can checksum all the packets.
> */
> + NETIF_F_HW_CSUM_ENC_BIT, /* Can checksum all inner headers */
> NETIF_F_IPV6_CSUM_BIT, /* Can checksum TCP/UDP over
> IPV6 */
Also #define NETIF_F_HW_CSUM_ENC should be added
^ permalink raw reply
* RE: [PATCH v2 3/3] ipgre: capture inner headers during encapsulation
From: Dmitry Kravkov @ 2012-11-14 12:32 UTC (permalink / raw)
To: Joseph Gasparakis, davem@davemloft.net, shemminger@vyatta.com,
chrisw@sous-sol.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter P Waskiewicz Jr
In-Reply-To: <1352689450-4092-1-git-send-email-joseph.gasparakis@intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Joseph Gasparakis
> Sent: Monday, November 12, 2012 5:04 AM
> To: davem@davemloft.net; shemminger@vyatta.com; chrisw@sous-sol.org
> Cc: Joseph Gasparakis; netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Peter P Waskiewicz Jr
> Subject: [PATCH v2 3/3] ipgre: capture inner headers during encapsulation
>
> Populating the inner header pointers of skb for ipgre
> This patch has been compile-tested only.
>
> v2 Makes sure that checksumming does not take place if the offload flag is set in
> the skb's netdev features
>
> Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> ---
> net/ipv4/ip_gre.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 7240f8e..e35ed52 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -766,8 +766,10 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff
> *skb, struct net_device *dev
> int gre_hlen;
> __be32 dst;
> int mtu;
> + unsigned int offset;
>
> - if (skb->ip_summed == CHECKSUM_PARTIAL &&
> + if (!(skb->dev->features & NETIF_F_HW_CSUM_ENC_BIT) &&
You should test for NETIF_F_HW_CSUM_ENC and not for NETIF_F_HW_CSUM_ENC_BIT
^ permalink raw reply
* [patch net] net: correct check in dev_addr_del()
From: Jiri Pirko @ 2012-11-14 12:51 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, shemminger, john.r.fastabend
Check (ha->addr == dev->dev_addr) is always true because dev_addr_init()
sets this. Correct the check to behave properly on addr removal.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/core/dev_addr_lists.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index 87cc17d..b079c7b 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -319,7 +319,8 @@ int dev_addr_del(struct net_device *dev, const unsigned char *addr,
*/
ha = list_first_entry(&dev->dev_addrs.list,
struct netdev_hw_addr, list);
- if (ha->addr == dev->dev_addr && ha->refcount == 1)
+ if (!memcmp(ha->addr, addr, dev->addr_len) &&
+ ha->type == addr_type && ha->refcount == 1)
return -ENOENT;
err = __hw_addr_del(&dev->dev_addrs, addr, dev->addr_len,
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] iputils: minor fixes
From: Jan Synacek @ 2012-11-14 12:57 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, Jan Synacek
Jan Synacek (2):
ping,ping6: Add newline to error message.
ping: Don't free an unintialized value.
ping.c | 8 +++++---
ping_common.c | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
--
1.7.11.7
^ 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