* Re: [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: David Miller @ 2011-04-07 6:05 UTC (permalink / raw)
To: therbert; +Cc: yjwei, netdev
In-Reply-To: <BANLkTikspQHnjagFme0S3GdPUo-zw48zBw@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 6 Apr 2011 21:50:55 -0700
> Nice catch.
>
> Acked-by: Tom Herbert <therbert@google.com>
>
> On Wed, Apr 6, 2011 at 9:40 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
>> commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
>> (net: Allow no-cache copy from user on transmit)
>> of checksum, which may cause some tcp packets be dropped because
>> incorrect checksum. ssh does not work under today's net-next-2.6
>> tree.
>>
>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Applied, thanks everyone.
^ permalink raw reply
* RE: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Salecha @ 2011-04-07 6:03 UTC (permalink / raw)
To: David Miller, bhutchings@solarflare.com
Cc: netdev@vger.kernel.org, Ameen Rahman, Anirban Chakraborty
In-Reply-To: <20110406.133019.212692386.davem@davemloft.net>
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 06 Apr 2011 21:20:47 +0100
>
> > Amit, I told you already that you must not use my Signed-off-by line
> > since you are changing the patch significantly.
>
> Amit, this is a very serious infraction.
>
> You must not ever add someone else's signed-off-by when you make
> changes to a patch, unless you have their very clear and explicit
> permission to do so.
As this patch is based on Ben patch, so I thought its my duty to add his Signed-off.
Then I misinterpreted Ben comment and thought he want me to explain his contribution.
Sorry Ben.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-07 5:42 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <20110406.223400.71127145.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Apr 2011 22:34:00 -0700 (PDT)
> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Thu, 07 Apr 2011 13:31:06 +0900
>
>> I'm not pretty sure though, output message is
>>
>> ip_finish_output2: No header cache and no neighbour!
>>
>> I'm not debugging this though,
>>
>> static inline bool rt_is_output_route(struct rtable *rt)
>> {
>> return rt->rt_iif == 0;
>> }
>>
>> from review I guess the above is one of cause.
>
> arp_bind_neighbour() is only called if rt_is_output_route() is true
> or route is unicast.
>
> If packet is sent using a route for which arp_bind_neighbour() has not
> been called, you will see that warning message.
Ok, the problem is that, for output routes in original code:
1) user's flow device index is stored in rt->rt_iif
2) arp_bind_neighbour() tests meanwhile used rt->fl.iif
So we do need, for now, to add a new member. But I think for
correct semantics it needs to have inverse meaning to the one
you added in your RFC patch.
So fix is something like:
1) Add "int rt_route_iif;" to struct rtable
2) For input routes, always set rt_route_iif to same value as rt_iif
3) For output routes, always set rt_route_iif to zero. Set rt_iif
as it is done currently.
4) Change rt_is_{output,input}_route() to test rt_route_iif
This should fix the bug and not introduce new regressions.
Can you write and test such a patch with your test case?
Thank you!
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-07 5:34 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <87ipuqsmwl.fsf@devron.myhome.or.jp>
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Thu, 07 Apr 2011 13:31:06 +0900
> I'm not pretty sure though, output message is
>
> ip_finish_output2: No header cache and no neighbour!
>
> I'm not debugging this though,
>
> static inline bool rt_is_output_route(struct rtable *rt)
> {
> return rt->rt_iif == 0;
> }
>
> from review I guess the above is one of cause.
arp_bind_neighbour() is only called if rt_is_output_route() is true
or route is unicast.
If packet is sent using a route for which arp_bind_neighbour() has not
been called, you will see that warning message.
^ permalink raw reply
* RE: Question on "net: allocate skbs on local node"
From: Eric Dumazet @ 2011-04-07 5:16 UTC (permalink / raw)
To: Wei Gu; +Cc: netdev, Alexander Duyck, Jeff Kirsher
In-Reply-To: <1302152327.2701.50.camel@edumazet-laptop>
Le jeudi 07 avril 2011 à 06:58 +0200, Eric Dumazet a écrit :
> Le jeudi 07 avril 2011 à 10:16 +0800, Wei Gu a écrit :
> > Hi Eric,
> > Testing with ixgbe Linux 2.6.38 driver:
> > We have a little better thruput figure with this driver, but it looks
> > not scalling at all, I always stressed one CPU core/24.
> > And when look the perf report for ksoftirqd/24, the most cost function
> > is still "_raw_spin_unlock_irqstore" and the IRQ/s is huge, it's
> > somehow conflicts with desgin of NAPI. On linux 2.6.32 while the CPU
> > was stressed the IRQ will descreased while the NAPI will running much
> > on the polling mode. I don't know why on 2.6.38 the IRQ was keep
> > increasing.
>
>
> CC netdev and Intel guys, since they said it should not happen (TM)
>
> IF you dont use DCA (make sure ioatdma module is not loaded), how comes
> alloc_iova() is called at all ?
>
> IF you use DCA, how comes its called, since the same CPU serves a given
> interrupt ?
>
>
But then, maybe you forgot to cpu affine IRQS ?
High performance routing setup is tricky, since you probably want to
disable many features that are ON by default : Most machines act as a
end host.
^ permalink raw reply
* Re: [PATCH net-next 1/5] be2net: add rxhash support
From: Eric Dumazet @ 2011-04-07 5:05 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev
In-Reply-To: <20110407040743.GA4183@akhaparde-VBox>
Le mercredi 06 avril 2011 à 23:07 -0500, Ajit Khaparde a écrit :
> Add rxhash support,
> Based on initial work by Eric Dumazet.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
> ---
> drivers/net/benet/be.h | 5 +++++
> drivers/net/benet/be_ethtool.c | 13 +++++++++++++
> drivers/net/benet/be_main.c | 17 ++++++++++++-----
> 3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
> index 0899d91..8941b98 100644
> --- a/drivers/net/benet/be.h
> +++ b/drivers/net/benet/be.h
> @@ -485,6 +485,11 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
> memcpy(mac, adapter->netdev->dev_addr, 3);
> }
>
> +static inline bool be_multi_rxq(struct be_adapter *adapter)
static inline bool be_multi_rxq(const struct be_adapter *adapter)
> +{
> + return (adapter->num_rx_qs > 1);
return adapter->num_rx_qs > 1;
> +}
> +
Other parts seems fine, thanks !
^ permalink raw reply
* RE: Question on "net: allocate skbs on local node"
From: Eric Dumazet @ 2011-04-07 4:58 UTC (permalink / raw)
To: Wei Gu; +Cc: netdev, Alexander Duyck, Jeff Kirsher
In-Reply-To: <D12839161ADD3A4B8DA63D1A134D084026E48B9BEB@ESGSCCMS0001.eapac.ericsson.se>
Le jeudi 07 avril 2011 à 10:16 +0800, Wei Gu a écrit :
> Hi Eric,
> Testing with ixgbe Linux 2.6.38 driver:
> We have a little better thruput figure with this driver, but it looks
> not scalling at all, I always stressed one CPU core/24.
> And when look the perf report for ksoftirqd/24, the most cost function
> is still "_raw_spin_unlock_irqstore" and the IRQ/s is huge, it's
> somehow conflicts with desgin of NAPI. On linux 2.6.32 while the CPU
> was stressed the IRQ will descreased while the NAPI will running much
> on the polling mode. I don't know why on 2.6.38 the IRQ was keep
> increasing.
CC netdev and Intel guys, since they said it should not happen (TM)
IF you dont use DCA (make sure ioatdma module is not loaded), how comes
alloc_iova() is called at all ?
IF you use DCA, how comes its called, since the same CPU serves a given
interrupt ?
>
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
>
> PerfTop: 512417 irqs/sec kernel:91.3% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 64 CPUs)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> - 0.82% ksoftirqd/24 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> \u2592 - _raw_spin_unlock_irqrestore
> \u2592 - 44.27% alloc_iova
> \u2592 intel_alloc_iova
> \u2592 __intel_map_single
> \u2592 intel_map_page
> \u2592 - ixgbe_init_interrupt_scheme
> \u2592 - 59.97% ixgbe_alloc_rx_buffers
> \u2592 ixgbe_clean_rx_irq
> \u2592 0xffffffffa033a5
> \u2592 net_rx_action
> u2592 __do_softirq
> \u2592 + call_softirq
> \u2592 - 40.03% ixgbe_change_mtu
> \u2592 ixgbe_change_mtu
> \u2592 dev_hard_start_xmit
> \u2592 sch_direct_xmit
> \u2592 dev_queue_xmit
> \u2592 vlan_dev_hard_start_xmit
> \u2592 hook_func
> \u2592 nf_iterate
> \u2592 nf_hook_slow
> \u2592 NF_HOOK.clone.1
> \u2592 ip_rcv
> \u2592 __netif_receive_skb
> \u2592 __netif_receive_skb
> \u2592 netif_receive_skb
> \u2592 napi_skb_finish
> \u2592 napi_gro_receive
> \u2592 ixgbe_clean_rx_irq
> \u2592 0xffffffffa033a5
> \u2592 net_rx_action
> \u2592 __do_softirq
> \u2592 + call_softirq
> \u2592 + 35.85% find_iova
> \u2592 + 19.44% add_unmap
>
>
> Thanks
> WeiGu
>
^ permalink raw reply
* Re: [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: Tom Herbert @ 2011-04-07 4:50 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <4D9D402C.60107@cn.fujitsu.com>
Nice catch.
Acked-by: Tom Herbert <therbert@google.com>
On Wed, Apr 6, 2011 at 9:40 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
> (net: Allow no-cache copy from user on transmit)
> of checksum, which may cause some tcp packets be dropped because
> incorrect checksum. ssh does not work under today's net-next-2.6
> tree.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> include/net/sock.h | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 43bd515..9cbf23c 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1392,14 +1392,14 @@ static inline void sk_nocaps_add(struct sock *sk, int flags)
>
> static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
> char __user *from, char *to,
> - int copy)
> + int copy, int offset)
> {
> if (skb->ip_summed == CHECKSUM_NONE) {
> int err = 0;
> __wsum csum = csum_and_copy_from_user(from, to, copy, 0, &err);
> if (err)
> return err;
> - skb->csum = csum_block_add(skb->csum, csum, skb->len);
> + skb->csum = csum_block_add(skb->csum, csum, offset);
> } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
> if (!access_ok(VERIFY_READ, from, copy) ||
> __copy_from_user_nocache(to, from, copy))
> @@ -1413,11 +1413,12 @@ static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
> static inline int skb_add_data_nocache(struct sock *sk, struct sk_buff *skb,
> char __user *from, int copy)
> {
> - int err;
> + int err, offset = skb->len;
>
> - err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy), copy);
> + err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy),
> + copy, offset);
> if (err)
> - __skb_trim(skb, skb->len);
> + __skb_trim(skb, offset);
>
> return err;
> }
> @@ -1429,8 +1430,8 @@ static inline int skb_copy_to_page_nocache(struct sock *sk, char __user *from,
> {
> int err;
>
> - err = skb_do_copy_data_nocache(sk, skb, from,
> - page_address(page) + off, copy);
> + err = skb_do_copy_data_nocache(sk, skb, from, page_address(page) + off,
> + copy, skb->len);
> if (err)
> return err;
>
> --
> 1.6.5.2
>
>
>
^ permalink raw reply
* [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: Wei Yongjun @ 2011-04-07 4:40 UTC (permalink / raw)
To: David Miller, Tom Herbert, netdev@vger.kernel.org
commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
(net: Allow no-cache copy from user on transmit)
of checksum, which may cause some tcp packets be dropped because
incorrect checksum. ssh does not work under today's net-next-2.6
tree.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
include/net/sock.h | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 43bd515..9cbf23c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1392,14 +1392,14 @@ static inline void sk_nocaps_add(struct sock *sk, int flags)
static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
char __user *from, char *to,
- int copy)
+ int copy, int offset)
{
if (skb->ip_summed == CHECKSUM_NONE) {
int err = 0;
__wsum csum = csum_and_copy_from_user(from, to, copy, 0, &err);
if (err)
return err;
- skb->csum = csum_block_add(skb->csum, csum, skb->len);
+ skb->csum = csum_block_add(skb->csum, csum, offset);
} else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
if (!access_ok(VERIFY_READ, from, copy) ||
__copy_from_user_nocache(to, from, copy))
@@ -1413,11 +1413,12 @@ static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
static inline int skb_add_data_nocache(struct sock *sk, struct sk_buff *skb,
char __user *from, int copy)
{
- int err;
+ int err, offset = skb->len;
- err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy), copy);
+ err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy),
+ copy, offset);
if (err)
- __skb_trim(skb, skb->len);
+ __skb_trim(skb, offset);
return err;
}
@@ -1429,8 +1430,8 @@ static inline int skb_copy_to_page_nocache(struct sock *sk, char __user *from,
{
int err;
- err = skb_do_copy_data_nocache(sk, skb, from,
- page_address(page) + off, copy);
+ err = skb_do_copy_data_nocache(sk, skb, from, page_address(page) + off,
+ copy, skb->len);
if (err)
return err;
--
1.6.5.2
^ permalink raw reply related
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: OGAWA Hirofumi @ 2011-04-07 4:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110406.132829.116375350.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Tue, 05 Apr 2011 22:05:10 +0900
>
>> ipv4: Set rt->rt_iif more sanely on output routes.
>> (1018b5c01636c7c6bda31a719bda34fc631db29a)
>>
>> The above patch seems to be caused of avahi breakage.
>>
>> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
>> in_pktinfo->ipi_ifindex > 0.
>>
>> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.
>
> in_pktinfo is given to the application only during recvmsg() calls, the
> call chain is (for example):
>
> udp_recvmsg()
> --> ip_cmsg_recv()
> --> ip_cmsg_recv_pktinfo()
>
> Therefore we will only be working with receive packets, whose routes are
> computed using ip_route_input*() which will fill in the rt_iif field
> appropriately.
>
> The only exception to this would be packets which are looped back, in
> which case the cached output route attached to the packet will be used.
I see.
> Your RFC patch should work, but we're trying to make "struct rtable"
> smaller rather than larger.
I felt it from git hisotry.
> In what way does routing break if you simply restore the original
> rt_iif assignment in output route creation? That's the most preferred
> fix for this.
I'm not pretty sure though, output message is
ip_finish_output2: No header cache and no neighbour!
I'm not debugging this though,
static inline bool rt_is_output_route(struct rtable *rt)
{
return rt->rt_iif == 0;
}
from review I guess the above is one of cause.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH net-next 5/5] be2net: call FLR after setup wol in be_shutdown
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Calling setup_wol after a reset is inconsequential.
The WOL setting should be programmed before FLR.
And yes, FLR does not erase wol information.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 6a43b26..a7a2dec 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -3188,11 +3188,11 @@ static void be_shutdown(struct pci_dev *pdev)
netif_device_detach(netdev);
- be_cmd_reset_function(adapter);
-
if (adapter->wol)
be_setup_wol(adapter, true);
+ be_cmd_reset_function(adapter);
+
pci_disable_device(pdev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 4/5] be2net: dynamically allocate adapter->vf_cfg
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Instead of a fixed sized array for vf_cfg, allocate the size dynamically
depending on number of VFs the device supports.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 4 +---
drivers/net/benet/be_main.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index eba405b..1d976b8 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -92,8 +92,6 @@ static inline char *nic_name(struct pci_dev *pdev)
#define FW_VER_LEN 32
-#define BE_MAX_VF 32
-
struct be_dma_mem {
void *va;
dma_addr_t dma;
@@ -336,7 +334,7 @@ struct be_adapter {
bool be3_native;
bool sriov_enabled;
- struct be_vf_cfg vf_cfg[BE_MAX_VF];
+ struct be_vf_cfg *vf_cfg;
u8 is_virtfn;
u32 sli_family;
u8 hba_port_num;
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 9d6982a..6a43b26 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2837,6 +2837,7 @@ static void __devexit be_remove(struct pci_dev *pdev)
be_ctrl_cleanup(adapter);
+ kfree(adapter->vf_cfg);
be_sriov_disable(adapter);
be_msix_disable(adapter);
@@ -3021,16 +3022,23 @@ static int __devinit be_probe(struct pci_dev *pdev,
}
be_sriov_enable(adapter);
+ if (adapter->sriov_enabled) {
+ adapter->vf_cfg = kcalloc(num_vfs,
+ sizeof(struct be_vf_cfg), GFP_KERNEL);
+
+ if (!adapter->vf_cfg)
+ goto free_netdev;
+ }
status = be_ctrl_init(adapter);
if (status)
- goto free_netdev;
+ goto free_vf_cfg;
if (lancer_chip(adapter)) {
status = lancer_test_and_set_rdy_state(adapter);
if (status) {
dev_err(&pdev->dev, "Adapter in non recoverable error\n");
- goto free_netdev;
+ goto ctrl_clean;
}
}
@@ -3092,6 +3100,8 @@ stats_clean:
be_stats_cleanup(adapter);
ctrl_clean:
be_ctrl_cleanup(adapter);
+free_vf_cfg:
+ kfree(adapter->vf_cfg);
free_netdev:
be_sriov_disable(adapter);
free_netdev(netdev);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 3/5] be2net: fix to get max VFs supported from adapter
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
The user supplied num_vfs value need not be compared
against a static BE_MAX_VF, but can be checked against
the actual VFs that the device can support.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 4910055..9d6982a 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1947,7 +1947,20 @@ static void be_sriov_enable(struct be_adapter *adapter)
be_check_sriov_fn_type(adapter);
#ifdef CONFIG_PCI_IOV
if (be_physfn(adapter) && num_vfs) {
- int status;
+ int status, pos;
+ u16 nvfs;
+
+ pos = pci_find_ext_capability(adapter->pdev,
+ PCI_EXT_CAP_ID_SRIOV);
+ pci_read_config_word(adapter->pdev,
+ pos + PCI_SRIOV_TOTAL_VF, &nvfs);
+
+ if (num_vfs > nvfs) {
+ dev_info(&adapter->pdev->dev,
+ "Device supports %d VFs and not %d\n",
+ nvfs, num_vfs);
+ num_vfs = nvfs;
+ }
status = pci_enable_sriov(adapter->pdev, num_vfs);
adapter->sriov_enabled = status ? false : true;
@@ -3281,13 +3294,6 @@ static int __init be_init_module(void)
rx_frag_size = 2048;
}
- if (num_vfs > 32) {
- printk(KERN_WARNING DRV_NAME
- " : Module param num_vfs must not be greater than 32."
- "Using 32\n");
- num_vfs = 32;
- }
-
return pci_register_driver(&be_driver);
}
module_init(be_init_module);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 1/5] be2net: add rxhash support
From: Ajit Khaparde @ 2011-04-07 4:07 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet
Add rxhash support,
Based on initial work by Eric Dumazet.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 5 +++++
drivers/net/benet/be_ethtool.c | 13 +++++++++++++
drivers/net/benet/be_main.c | 17 ++++++++++++-----
3 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index 0899d91..8941b98 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -485,6 +485,11 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
memcpy(mac, adapter->netdev->dev_addr, 3);
}
+static inline bool be_multi_rxq(struct be_adapter *adapter)
+{
+ return (adapter->num_rx_qs > 1);
+}
+
extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
u16 num_popped);
extern void be_link_status_update(struct be_adapter *adapter, bool link_up);
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index a665697..1565c81 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -735,6 +735,18 @@ be_read_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom,
return status;
}
+static int be_set_flags(struct net_device *netdev, u32 data)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+ int rc = -1;
+
+ if (be_multi_rxq(adapter))
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXHASH |
+ ETH_FLAG_TXVLAN | ETH_FLAG_RXVLAN);
+
+ return rc;
+}
+
const struct ethtool_ops be_ethtool_ops = {
.get_settings = be_get_settings,
.get_drvinfo = be_get_drvinfo,
@@ -764,4 +776,5 @@ const struct ethtool_ops be_ethtool_ops = {
.get_regs = be_get_regs,
.flash_device = be_do_flash,
.self_test = be_self_test,
+ .set_flags = be_set_flags,
};
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a24fb45..4910055 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -116,11 +116,6 @@ static char *ue_status_hi_desc[] = {
"Unknown"
};
-static inline bool be_multi_rxq(struct be_adapter *adapter)
-{
- return (adapter->num_rx_qs > 1);
-}
-
static void be_queue_free(struct be_adapter *adapter, struct be_queue_info *q)
{
struct be_dma_mem *mem = &q->dma_mem;
@@ -1012,6 +1007,9 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = rxcp->rss_hash;
+
if (unlikely(rxcp->vlanf)) {
if (!adapter->vlan_grp || adapter->vlans_added == 0) {
@@ -1072,6 +1070,8 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
skb->data_len = rxcp->pkt_size;
skb->truesize += rxcp->pkt_size;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = rxcp->rss_hash;
if (likely(!rxcp->vlanf))
napi_gro_frags(&eq_obj->napi);
@@ -1101,6 +1101,8 @@ static void be_parse_rx_compl_v1(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, cast_enc, compl);
+ rxcp->rss_hash =
+ AMAP_GET_BITS(struct amap_eth_rx_compl_v1, rsshash, rxcp);
if (rxcp->vlanf) {
rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm,
compl);
@@ -1131,6 +1133,8 @@ static void be_parse_rx_compl_v0(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, cast_enc, compl);
+ rxcp->rss_hash =
+ AMAP_GET_BITS(struct amap_eth_rx_compl_v0, rsshash, rxcp);
if (rxcp->vlanf) {
rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm,
compl);
@@ -2614,6 +2618,9 @@ static void be_netdev_init(struct net_device *netdev)
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
+ if (be_multi_rxq(adapter))
+ netdev->features |= NETIF_F_RXHASH;
+
netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/5] be2net: use common method to check for sriov function type
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Lancer and BE can both use SLI_INTF_REG to check a VF or a PF.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index 8941b98..eba405b 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -458,18 +458,10 @@ static inline u8 is_udp_pkt(struct sk_buff *skb)
static inline void be_check_sriov_fn_type(struct be_adapter *adapter)
{
- u8 data;
u32 sli_intf;
- if (lancer_chip(adapter)) {
- pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET,
- &sli_intf);
- adapter->is_virtfn = (sli_intf & SLI_INTF_FT_MASK) ? 1 : 0;
- } else {
- pci_write_config_byte(adapter->pdev, 0xFE, 0xAA);
- pci_read_config_byte(adapter->pdev, 0xFE, &data);
- adapter->is_virtfn = (data != 0xAA);
- }
+ pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
+ adapter->is_virtfn = (sli_intf & SLI_INTF_FT_MASK) ? 1 : 0;
}
static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 0/5] be2net: Patch series
From: Ajit Khaparde @ 2011-04-07 4:07 UTC (permalink / raw)
To: netdev
Series of 5 patches. Please apply.
Thanks
-Ajit
[1/5] add rxhash support
[2/5] use common method to check for sriov function type
[3/5] fix to get max VFs supported from adapter
[4/5] dynamically allocate adapter->vf_cfg
[5/5] call FLR after setup wol in be_shutdown
^ permalink raw reply
* (unknown),
From: Wang Lei @ 2011-04-07 3:22 UTC (permalink / raw)
I'm Wang Lei, I have a deal worth 25 Million USD if interested, please contact me via my personal email: wlei2344@gala.net
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2011-04-07 1:39 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Sathya Perla, Ajit Khaparde
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/benet/be_main.c between commit 2d5d41546504 ("be2net: Fix a
potential crash during shutdown.") from the net-current tree and commit
0f4a68288217 ("be2net: cancel be_worker in be_shutdown() even when i/f is
down") from the net tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/benet/be_main.c
index 88d4c80,a24fb45..0000000
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@@ -3142,14 -3152,11 +3153,13 @@@ static int be_resume(struct pci_dev *pd
static void be_shutdown(struct pci_dev *pdev)
{
struct be_adapter *adapter = pci_get_drvdata(pdev);
- struct net_device *netdev = adapter->netdev;
+
+ if (!adapter)
+ return;
- if (netif_running(adapter->netdev))
- cancel_delayed_work_sync(&adapter->work);
+ cancel_delayed_work_sync(&adapter->work);
- netif_device_detach(netdev);
+ netif_device_detach(adapter->netdev);
be_cmd_reset_function(adapter);
^ permalink raw reply
* Re: ipv6: Add support for RTA_PREFSRC
From: David Miller @ 2011-04-07 1:37 UTC (permalink / raw)
To: dwalter; +Cc: netdev
In-Reply-To: <1301903804.31789.234.camel@localhost>
From: Daniel Walter <dwalter@barracuda.com>
Date: Mon, 4 Apr 2011 09:56:44 +0200
> On Fri, 2011-04-01 at 20:46 -0700, David Miller wrote:
>> You can't change the layout of "struct in6_rtmsg", as that structure
>> is explicitly exported to user space and changing it will break every
>> application out there.
>
> Hi,
>
> I've kicked support for setting the preferred source via ioctl,
> to keep "struct in6_rtmsg" untouched.
> This reduces the RTA_PREFSRC support to netlink only, unless
> we break the struct.
>
> Do you see any other way around this problem?
This is fine, adding new feature support to deprecated things like
the ioctl routing calls is undesirable anyways.
Since you do the prefsrc extraction in at least two places, make a
helper function that does the whole "if prefsrc.plen use prefsrc, else
use ipv6_dev_get_saddr()"
This would be akin to ipv4's FIB_RES_PREFSRC
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id
From: Ben Hutchings @ 2011-04-07 0:35 UTC (permalink / raw)
To: Casey Leedom
Cc: Stephen Hemminger, Dimitris Michailidis, David Miller, netdev
In-Reply-To: <201104061720.30219.leedom@chelsio.com>
On Wed, 2011-04-06 at 17:20 -0700, Casey Leedom wrote:
> | From: Stephen Hemminger <shemminger@linux-foundation.org>
> | Date: Wednesday, April 06, 2011 05:09 pm
> |
> | The Chelsio cxgb4 drivers implement blinking in a unique way by
> | waiting on the mailbox. This patch cleans it up slightly by no longer
> | holding the system wide network configuration lock during the process.
> |
> | The patch also uses correct semantics for the time argument
> | which is supposed to be in seconds; and zero is supposed
> | to signify infinite blinking.
> |
> | This is still a bad firmware interface design for this
> | since it means the board is basically hung while doing the blink.
> | But fixing it correctly would require hardware and firmware
> | documentation. With that information the device could be converted
> | to the new set_phys_id.
> |
> | Compile tested only.
> |
> | Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Are you assuming that the firmware won't respond with a command completion
> until the LED blinking is complete? If so, that's a bad assumption. The
> firmware runs as an asynchronous real-time OS. The LED blinking simply becomes
> a thread of activity within the OS and the command completes immediately.
[...]
Stephen was assuming (as I did) that you actually implemented this
operation correctly. You're supposed to blink the LED for the specified
time but let the user interrupt early. If you just start the LED
blinking and then return, then it appears the user has no way to
interrupt it.
Is there a defined firmware command to stop blinking the LED?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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-next] cxgb4: don't hold RTNL during ethtool phys_id
From: Stephen Hemminger @ 2011-04-07 0:33 UTC (permalink / raw)
To: Casey Leedom; +Cc: Dimitris Michailidis, Ben Hutchings, David Miller, netdev
In-Reply-To: <201104061720.30219.leedom@chelsio.com>
On Wed, 6 Apr 2011 17:20:29 -0700
Casey Leedom <leedom@chelsio.com> wrote:
> | From: Stephen Hemminger <shemminger@linux-foundation.org>
> | Date: Wednesday, April 06, 2011 05:09 pm
> |
> | The Chelsio cxgb4 drivers implement blinking in a unique way by
> | waiting on the mailbox. This patch cleans it up slightly by no longer
> | holding the system wide network configuration lock during the process.
> |
> | The patch also uses correct semantics for the time argument
> | which is supposed to be in seconds; and zero is supposed
> | to signify infinite blinking.
> |
> | This is still a bad firmware interface design for this
> | since it means the board is basically hung while doing the blink.
> | But fixing it correctly would require hardware and firmware
> | documentation. With that information the device could be converted
> | to the new set_phys_id.
> |
> | Compile tested only.
> |
> | Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Are you assuming that the firmware won't respond with a command completion
> until the LED blinking is complete? If so, that's a bad assumption. The
> firmware runs as an asynchronous real-time OS. The LED blinking simply becomes
> a thread of activity within the OS and the command completes immediately.
>
> Casey
Then how is LED blinking stopped?
^ permalink raw reply
* Associate Needed Asap
From: Song Lile @ 2011-04-06 22:04 UTC (permalink / raw)
Good Day,
My name is Mr. Song Lile, I am the credit officer in Hang Seng Bank, Hong
Kong. I have a business proposal of certain amount of funds to be transferred
to an offshore account with your assistace if willing.
After the successful transfer, we shall share in ratio of 30% for you and
70% for me. Should you be interested, please respond to my letter
immediately, so we can commence all arrangements and I will give you more
information on the project and how we would handle it.
You can contact me on my private email:( sogli903@asus.hk )
and send me the following information for documentation purpose:
1. Full names
2. Private phone number
3. Current residential address
I look forward to hearing from you.
Kind Regards,
Mr. Song Lile.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id
From: Casey Leedom @ 2011-04-07 0:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Dimitris Michailidis, Ben Hutchings, David Miller, netdev
In-Reply-To: <20110406170929.6e427b36@nehalam>
| From: Stephen Hemminger <shemminger@linux-foundation.org>
| Date: Wednesday, April 06, 2011 05:09 pm
|
| The Chelsio cxgb4 drivers implement blinking in a unique way by
| waiting on the mailbox. This patch cleans it up slightly by no longer
| holding the system wide network configuration lock during the process.
|
| The patch also uses correct semantics for the time argument
| which is supposed to be in seconds; and zero is supposed
| to signify infinite blinking.
|
| This is still a bad firmware interface design for this
| since it means the board is basically hung while doing the blink.
| But fixing it correctly would require hardware and firmware
| documentation. With that information the device could be converted
| to the new set_phys_id.
|
| Compile tested only.
|
| Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Are you assuming that the firmware won't respond with a command completion
until the LED blinking is complete? If so, that's a bad assumption. The
firmware runs as an asynchronous real-time OS. The LED blinking simply becomes
a thread of activity within the OS and the command completes immediately.
Casey
| ---
| drivers/net/cxgb4/cxgb4_main.c | 17 ++++++++++++++---
| drivers/net/cxgb4vf/cxgb4vf_main.c | 21 +++++++++++++++++++--
| 2 files changed, 33 insertions(+), 5 deletions(-)
|
| --- a/drivers/net/cxgb4/cxgb4_main.c 2011-04-06 16:49:02.045648800 -0700
| +++ b/drivers/net/cxgb4/cxgb4_main.c 2011-04-06 17:00:59.508851692 -0700
| @@ -1339,12 +1339,23 @@ static int restart_autoneg(struct net_de
| static int identify_port(struct net_device *dev, u32 data)
| {
| struct adapter *adap = netdev2adap(dev);
| + int rc;
| + unsigned long blinks;
|
| if (data == 0)
| - data = 2; /* default to 2 seconds */
| + blinks = UINT_MAX;
| + else
| + blinks = 2*data + data/2;
|
| - return t4_identify_port(adap, adap->fn, netdev2pinfo(dev)->viid,
| - data * 5);
| + /* Don't block networking updates while blink is in progress */
| + dev_hold(dev);
| + rtnl_unlock();
| +
| + rc = t4_identify_port(adap, adap->fn, netdev2pinfo(dev)->viid,
| + blinks);
| + rtnl_lock();
| + dev_put(dev);
| + return rc;
| }
|
| static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
| --- a/drivers/net/cxgb4vf/cxgb4vf_main.c 2011-04-06 16:49:09.989728600
| -0700 +++ b/drivers/net/cxgb4vf/cxgb4vf_main.c 2011-04-06
| 17:02:38.609846223 -0700 @@ -43,6 +43,7 @@
| #include <linux/etherdevice.h>
| #include <linux/debugfs.h>
| #include <linux/ethtool.h>
| +#include <linux/rtnetlink.h>
|
| #include "t4vf_common.h"
| #include "t4vf_defs.h"
| @@ -1352,11 +1353,27 @@ static int cxgb4vf_set_rx_csum(struct ne
| /*
| * Identify the port by blinking the port's LED.
| */
| -static int cxgb4vf_phys_id(struct net_device *dev, u32 id)
| +static int cxgb4vf_phys_id(struct net_device *dev, u32 data)
| {
| struct port_info *pi = netdev_priv(dev);
| + int rc;
| + unsigned int blinks;
|
| - return t4vf_identify_port(pi->adapter, pi->viid, 5);
| + if (data == 0)
| + blinks = UINT_MAX;
| + else
| + blinks = 2*data + data/2;
| +
| + /* Don't block networking updates while blink is in progress */
| + dev_hold(dev);
| + rtnl_unlock();
| +
| + rc = t4vf_identify_port(pi->adapter, pi->viid, blinks);
| +
| + rtnl_lock();
| + dev_put(dev);
| +
| + return rc;
| }
|
| /*
^ permalink raw reply
* [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id
From: Stephen Hemminger @ 2011-04-07 0:09 UTC (permalink / raw)
To: Dimitris Michailidis, Casey Leedom, Ben Hutchings, David Miller; +Cc: netdev
The Chelsio cxgb4 drivers implement blinking in a unique way by
waiting on the mailbox. This patch cleans it up slightly by no longer
holding the system wide network configuration lock during the process.
The patch also uses correct semantics for the time argument
which is supposed to be in seconds; and zero is supposed
to signify infinite blinking.
This is still a bad firmware interface design for this
since it means the board is basically hung while doing the blink.
But fixing it correctly would require hardware and firmware
documentation. With that information the device could be converted
to the new set_phys_id.
Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/cxgb4/cxgb4_main.c | 17 ++++++++++++++---
drivers/net/cxgb4vf/cxgb4vf_main.c | 21 +++++++++++++++++++--
2 files changed, 33 insertions(+), 5 deletions(-)
--- a/drivers/net/cxgb4/cxgb4_main.c 2011-04-06 16:49:02.045648800 -0700
+++ b/drivers/net/cxgb4/cxgb4_main.c 2011-04-06 17:00:59.508851692 -0700
@@ -1339,12 +1339,23 @@ static int restart_autoneg(struct net_de
static int identify_port(struct net_device *dev, u32 data)
{
struct adapter *adap = netdev2adap(dev);
+ int rc;
+ unsigned long blinks;
if (data == 0)
- data = 2; /* default to 2 seconds */
+ blinks = UINT_MAX;
+ else
+ blinks = 2*data + data/2;
- return t4_identify_port(adap, adap->fn, netdev2pinfo(dev)->viid,
- data * 5);
+ /* Don't block networking updates while blink is in progress */
+ dev_hold(dev);
+ rtnl_unlock();
+
+ rc = t4_identify_port(adap, adap->fn, netdev2pinfo(dev)->viid,
+ blinks);
+ rtnl_lock();
+ dev_put(dev);
+ return rc;
}
static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c 2011-04-06 16:49:09.989728600 -0700
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c 2011-04-06 17:02:38.609846223 -0700
@@ -43,6 +43,7 @@
#include <linux/etherdevice.h>
#include <linux/debugfs.h>
#include <linux/ethtool.h>
+#include <linux/rtnetlink.h>
#include "t4vf_common.h"
#include "t4vf_defs.h"
@@ -1352,11 +1353,27 @@ static int cxgb4vf_set_rx_csum(struct ne
/*
* Identify the port by blinking the port's LED.
*/
-static int cxgb4vf_phys_id(struct net_device *dev, u32 id)
+static int cxgb4vf_phys_id(struct net_device *dev, u32 data)
{
struct port_info *pi = netdev_priv(dev);
+ int rc;
+ unsigned int blinks;
- return t4vf_identify_port(pi->adapter, pi->viid, 5);
+ if (data == 0)
+ blinks = UINT_MAX;
+ else
+ blinks = 2*data + data/2;
+
+ /* Don't block networking updates while blink is in progress */
+ dev_hold(dev);
+ rtnl_unlock();
+
+ rc = t4vf_identify_port(pi->adapter, pi->viid, blinks);
+
+ rtnl_lock();
+ dev_put(dev);
+
+ return rc;
}
/*
^ permalink raw reply
* Re: [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: David Miller @ 2011-04-06 23:48 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110406160713.7ff48ef1@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 6 Apr 2011 16:07:13 -0700
> Begin forwarded message:
>
> Date: Wed, 6 Apr 2011 22:42:39 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 32832] New: shutdown(2) does not fully shut down socket any more
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=32832
>
> Summary: shutdown(2) does not fully shut down socket any more
...
>
> In 2.6.35 and earlier, shutdown(2) will fully remove a socket. This does not
> appear to be true any more and is causing software to misbehave.
>
This is already being discussed:
http://marc.info/?l=linux-netdev&m=130176733401613&w=2
^ 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