* [PATCH net-next-2.6 7/8] sctp: Allow bindx_del to accept 0 port
From: Wei Yongjun @ 2011-04-19 5:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
We allow 0 port when adding new addresses. It only
makes sence to allow 0 port when removing addresses.
When removing the currently bound port will be used
when the port in the address is set to 0.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/socket.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 5c9980a..431b890 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -658,11 +658,15 @@ static int sctp_bindx_rem(struct sock *sk, struct sockaddr *addrs, int addrcnt)
goto err_bindx_rem;
}
- if (sa_addr->v4.sin_port != htons(bp->port)) {
+ if (sa_addr->v4.sin_port &&
+ sa_addr->v4.sin_port != htons(bp->port)) {
retval = -EINVAL;
goto err_bindx_rem;
}
+ if (!sa_addr->v4.sin_port)
+ sa_addr->v4.sin_port = htons(bp->port);
+
/* FIXME - There is probably a need to check if sk->sk_saddr and
* sk->sk_rcv_addr are currently set to one of the addresses to
* be removed. This is something which needs to be looked into
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 8/8] sctp: Release all routes when processing acks ADD_IP or DEL_IP
From: Wei Yongjun @ 2011-04-19 5:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
When processing an ACK for ADD_IP parameter, we only release
the routes on non-active transports. This can cause a wrong
source address to be used. We can release the routes and
cause new route lookups and source address selection so that
new addresses can be used as source. Additionally, we don't need
to lookup routes for all transports at the same time. We can let
the transmit code path update the cached route when the transport
actually sends something.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/sm_make_chunk.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 844adfd..f87ccb1 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3193,11 +3193,8 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
local_bh_enable();
list_for_each_entry(transport, &asoc->peer.transport_addr_list,
transports) {
- if (transport->state == SCTP_ACTIVE)
- continue;
dst_release(transport->dst);
- sctp_transport_route(transport, NULL,
- sctp_sk(asoc->base.sk));
+ transport->dst = NULL;
}
break;
case SCTP_PARAM_DEL_IP:
@@ -3207,8 +3204,7 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
list_for_each_entry(transport, &asoc->peer.transport_addr_list,
transports) {
dst_release(transport->dst);
- sctp_transport_route(transport, NULL,
- sctp_sk(asoc->base.sk));
+ transport->dst = NULL;
}
break;
default:
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 1/8 v2] sctp: delete unused macro definition of sctp_chunk_is_control
From: Wei Yongjun @ 2011-04-19 5:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD1915.70503@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
The macro never be used.
And if needed, can use !sctp_chunk_is_data instead of.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
Sorry for missing 'From ...' in the first version
---
include/net/sctp/constants.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index c70d8cc..deac13d 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -150,7 +150,6 @@ SCTP_SUBTYPE_CONSTRUCTOR(OTHER, sctp_event_other_t, other)
SCTP_SUBTYPE_CONSTRUCTOR(PRIMITIVE, sctp_event_primitive_t, primitive)
-#define sctp_chunk_is_control(a) (a->chunk_hdr->type != SCTP_CID_DATA)
#define sctp_chunk_is_data(a) (a->chunk_hdr->type == SCTP_CID_DATA)
/* Calculate the actual data size in a data chunk */
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Shan Wei @ 2011-04-19 5:31 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
Wei Yongjun wrote, at 04/19/2011 01:07 PM:
> Series of 8 patches against net-next-2.6, include some cleanup
> and tiny fix for add/del ip, which have been waiting on vlad's
> lksctp-dev tree for long times.
Thanks for your job, and expect others.
>
> Shan Wei (5):
> sctp: delete unused macro definition of sctp_chunk_is_control
> sctp: fix the comment of sctp_sf_violation_paramlen()
> sctp: use common head of addr parameter to access member in addr-unrelated code
> sctp: kill abandoned SCTP_CMD_TRANSMIT command
> sctp: use memdup_user to copy data from userspace
>
> Vlad Yasevich (3):
> sctp: teach CACC algorithm about removed transports
> sctp: Allow bindx_del to accept 0 port.
> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>
> include/net/sctp/command.h | 1 -
> include/net/sctp/constants.h | 1 -
> net/sctp/input.c | 2 +-
> net/sctp/outqueue.c | 11 ++++++++---
> net/sctp/sm_make_chunk.c | 18 +++++++-----------
> net/sctp/sm_sideeffect.c | 6 ------
> net/sctp/sm_statefuns.c | 5 +++--
> net/sctp/socket.c | 28 +++++++++++-----------------
> 8 files changed, 30 insertions(+), 42 deletions(-)
>
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH] acenic: Fix using the specified speed when configuring NIC
From: David Miller @ 2011-04-19 5:46 UTC (permalink / raw)
To: decot; +Cc: jes, linux-acenic, netdev, linux-kernel
In-Reply-To: <1303001827-4283-1-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Sat, 16 Apr 2011 17:57:07 -0700
> This patch needs review, as I did not test it: I only think something
> is weird by looking at the code, but experts must confirm.
>
> This tells the NIC to take the speed specified by ethtool into account
> when configuring the NIC, instead of keeping the previous speed.
>
> Signed-off-by: David Decotigny <decot@google.com>
Looks correct, but seems to be dependent upon some other patches which
have feedback pending which you need to address.
Please resubmit that when the other series ends up being applied after
you've fixed it up.
^ permalink raw reply
* Re: [PATCH] net: myri10ge: convert to hw_features
From: David Miller @ 2011-04-19 5:49 UTC (permalink / raw)
To: mirq-linux; +Cc: jon.mason, netdev, gallatin, brice
In-Reply-To: <20110418110347.GA18324@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Mon, 18 Apr 2011 13:03:47 +0200
> On Sun, Apr 17, 2011 at 11:30:53PM -0700, David Miller wrote:
>> From: Jon Mason <jon.mason@myri.com>
>> Date: Fri, 15 Apr 2011 13:29:22 -0500
>>
>> > On Fri, Apr 15, 2011 at 04:50:50PM +0200, Michał Mirosław wrote:
>> >> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>> >> ---
>> >> drivers/net/myri10ge/myri10ge.c | 66 +++++++-------------------------------
>> >> 1 files changed, 12 insertions(+), 54 deletions(-)
>> >>
>> >> diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
>> >> index 1446de5..a48eb92 100644
>> >> --- a/drivers/net/myri10ge/myri10ge.c
>> >> +++ b/drivers/net/myri10ge/myri10ge.c
>> >> @@ -205,7 +205,6 @@ struct myri10ge_priv {
>> >> int tx_boundary; /* boundary transmits cannot cross */
>> >> int num_slices;
>> >> int running; /* running? */
>> >> - int csum_flag; /* rx_csums? */
>> > Get rid of MXGEFW_FLAGS_CKSUM in drivers/net/myri10ge/myri10ge_mcp.h,
>> > as this was the only thing using it.
>> ...
>> > ethtool_op_set_tso does not support TSO6. This would remove the
>> > enable/disable of that feature.
>> Michał please fix these issues and resubmit this patch, thanks!
>
> There are no issues. MXGEFW_FLAGS_CKSUM is used elsewhere in the driver
> and TSO6 is handled by masking netdev->hw_features at devinit time.
>
> BTW, ethtool_op_set_tso() is not used at all in new offload changing scheme.
Ok, applied, thanks!
^ permalink raw reply
* Re: [PATCH v2] net: r8169: convert to hw_features
From: David Miller @ 2011-04-19 5:54 UTC (permalink / raw)
To: romieu; +Cc: dave, netdev, nic_swsd
In-Reply-To: <20110418180857.GB18469@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 18 Apr 2011 20:08:57 +0200
> [...]
>> I've attached my ancient patch, if it helps.
>
> Thanks, it works way better now (see below). It is ok for me to use
> you s-o-b on it ?
>
> I have given it a try on 8169, 8168b, 8168d, 8102e and the load can
> dramatically fall (more at 1000 Mbps than at 100 Mbps).
>
> David (M.), should it go through net-next or be made ready for net-2.6 ?
>
> Subject: [PATCH] r8169: TSO fixes.
Francois, since TSO is disabled by default I'm applying this to
net-next-2.6, thanks!
Maybe we can progressively start to try and turn these things on
by default now that we know more about the TX descriptor layout
differences.
^ permalink raw reply
* Re: [PATCH net-next 4/5] be2net: pass domain id to be_cmd_link_status_query
From: David Miller @ 2011-04-19 5:56 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110418223033.GA9515@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Mon, 18 Apr 2011 17:30:33 -0500
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
That's not all this patch does:
> @@ -293,7 +293,6 @@ struct be_adapter {
> u8 eq_next_idx;
> struct be_drv_stats drv_stats;
>
> - struct vlan_group *vlan_grp;
> u16 vlans_added;
> u16 max_vlans; /* Number of vlans supported */
> u8 vlan_tag[VLAN_N_VID];
...
> @@ -1012,15 +1004,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
> skb->rxhash = rxcp->rss_hash;
>
>
> - if (unlikely(rxcp->vlanf)) {
> - if (!adapter->vlan_grp || adapter->vlans_added == 0) {
> - kfree_skb(skb);
> - return;
> - }
> - vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
> - } else {
> - netif_receive_skb(skb);
> - }
> + if (unlikely(rxcp->vlanf))
> + __vlan_hwaccel_put_tag(skb, rxcp->vid);
> +
> + netif_receive_skb(skb);
> }
>
> /* Process the RX completion indicated by rxcp when GRO is enabled */
It seems to be also converting the driver over to the new VLAN
interfaces.
Please seperate this part into a seperate patch and resubmit your
patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: fix section mismatches
From: David Miller @ 2011-04-19 5:59 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, klassert, perex, samuel, grundler
In-Reply-To: <20110418233120.E4B1F138DD@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> Fix build warnings like the following:
>
> WARNING: drivers/net/built-in.o(.data+0x12434): Section mismatch in reference from the variable madgemc_driver to the variable .init.data:madgemc_adapter_ids
>
> And add some consts to EISA device ID tables along the way.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
I've applied this, thanks!
^ permalink raw reply
* Re: [PATCH v2] net: chelsio: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110418233120.CCB2313909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> Also remove flags that were not used or are now redundant to hw_features bits.
> No device had UDP_CSUM_CAPABLE set.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> v2: fix usage of uninitialized variable in sge_rx()
Applied.
^ permalink raw reply
* Re: [PATCH] net: qlge: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, ron.mercer, linux-driver
In-Reply-To: <20110418233121.2FF0113A65@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> Another simple conversion.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: s2io: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, jdmason
In-Reply-To: <20110418233121.1726C13A64@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> This removes advertising HW_CSUM as driver does not support it.
>
> Note: driver advertises TSO6 but not IPV6_CSUM - bug maybe?
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Yes it's probably a bug. Since, as I understand it, this driver is
in pretty deep maintainence mode the best thing to do is probably
to remove the TSO6 flag.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: vmxnet3: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, sbhatewara, pv-drivers
In-Reply-To: <20110418233121.AEC4913A68@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> This also removes private feature flags that were always set to true.
>
> You may want to move vmxnet3_set_features() to vmxnet3_drv.c as a following
> cleanup.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: vxge: convert to hw_features
From: David Miller @ 2011-04-19 6:05 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, jdmason
In-Reply-To: <20110418233121.5D8BB13A66@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> Side effect: ->gro_enable is removed as napi_gro_receive() does the
> fallback itself.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2011-04-19 7:41 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, yanivr, shemminger
In-Reply-To: <20110419131618.a474326a.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 19 Apr 2011 13:16:18 +1000
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/bnx2x/bnx2x_ethtool.c between commit 70dda99c41fc ("bnx2x:
> Fix port identification problem") from the net-current tree and commit
> 32d3613475d8 ("bnx2x: convert to set_phys_id") from the net tree.
>
> I fixed it up (maybe - see below) and can carry the fix as necessary.
Your conflict resolution was pretty much perfect :-)
I've merged net-2.6 into net-next-2.6 to fix this up.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Nicolas Dichtel @ 2011-04-19 8:10 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
Hi Wei Yongjun,
do you plan to send other patches, like "sctp: make sctp over IPv6 work with
IPsec.", too?
Regards,
Nicolas
Le 19/04/2011 07:07, Wei Yongjun a écrit :
> Series of 8 patches against net-next-2.6, include some cleanup
> and tiny fix for add/del ip, which have been waiting on vlad's
> lksctp-dev tree for long times.
>
> Shan Wei (5):
> sctp: delete unused macro definition of sctp_chunk_is_control
> sctp: fix the comment of sctp_sf_violation_paramlen()
> sctp: use common head of addr parameter to access member in addr-unrelated code
> sctp: kill abandoned SCTP_CMD_TRANSMIT command
> sctp: use memdup_user to copy data from userspace
>
> Vlad Yasevich (3):
> sctp: teach CACC algorithm about removed transports
> sctp: Allow bindx_del to accept 0 port.
> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>
> include/net/sctp/command.h | 1 -
> include/net/sctp/constants.h | 1 -
> net/sctp/input.c | 2 +-
> net/sctp/outqueue.c | 11 ++++++++---
> net/sctp/sm_make_chunk.c | 18 +++++++-----------
> net/sctp/sm_sideeffect.c | 6 ------
> net/sctp/sm_statefuns.c | 5 +++--
> net/sctp/socket.c | 28 +++++++++++-----------------
> 8 files changed, 30 insertions(+), 42 deletions(-)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Wei Yongjun @ 2011-04-19 8:18 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD438D.8040506@6wind.com>
> Hi Wei Yongjun,
>
> do you plan to send other patches, like "sctp: make sctp over IPv6 work with IPsec.", too?
Yes, I am doing this work now. And will commit those patch after backport
to net-next-2.6 tree and testing.
>
>
> Regards,
> Nicolas
>
> Le 19/04/2011 07:07, Wei Yongjun a écrit :
>> Series of 8 patches against net-next-2.6, include some cleanup
>> and tiny fix for add/del ip, which have been waiting on vlad's
>> lksctp-dev tree for long times.
>>
>> Shan Wei (5):
>> sctp: delete unused macro definition of sctp_chunk_is_control
>> sctp: fix the comment of sctp_sf_violation_paramlen()
>> sctp: use common head of addr parameter to access member in addr-unrelated code
>> sctp: kill abandoned SCTP_CMD_TRANSMIT command
>> sctp: use memdup_user to copy data from userspace
>>
>> Vlad Yasevich (3):
>> sctp: teach CACC algorithm about removed transports
>> sctp: Allow bindx_del to accept 0 port.
>> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>>
>> include/net/sctp/command.h | 1 -
>> include/net/sctp/constants.h | 1 -
>> net/sctp/input.c | 2 +-
>> net/sctp/outqueue.c | 11 ++++++++---
>> net/sctp/sm_make_chunk.c | 18 +++++++-----------
>> net/sctp/sm_sideeffect.c | 6 ------
>> net/sctp/sm_statefuns.c | 5 +++--
>> net/sctp/socket.c | 28 +++++++++++-----------------
>> 8 files changed, 30 insertions(+), 42 deletions(-)
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Add NAPI support to ll_temac driver
From: Michal Simek @ 2011-04-19 9:35 UTC (permalink / raw)
To: netdev
Hi,
I would like to try to add NAPI support for ll_temac and look if help us to
improve performance on Microblaze system. I would expect that bandwidth should
be increased.
We have the second non mainline driver which use tasklets and it provides better
performance than mainline driver but not so big that's why I think that NAPI
can increase performance.
Can you please point me to any driver which I could use as a template?
Or any developer guide to do so.
Do you know any other option how to improve driver performance on low speed cpu?
I have found that driver spends a lot of time on skb allocation and preallocated
SKBs help a little bit. I have done a test where I increased number of
preallocated BDs(SKBs) for rx to 35000 and disable new BD(SKB) allocation in
rx_irq. 35000 BDs is setup because I need them to successfully finish netperf
test. I have got 25% bandwidth increasing.
It will be also nice to be able to allocate several BDs(SKBs) which could be
faster than allocate them in sequence.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Hight speed data sending from custom IP out of kernel
From: Michal Simek @ 2011-04-19 9:49 UTC (permalink / raw)
To: netdev
Hi,
I would like to create demo for high speed data sending from custom IP through
the ethernet. I think the best description is that there are dmaable memory
mapped registers or just memory which store data I want to send (for example 200MB).
Linux should handle all communication between target(probably server) and host
(client) but data in the packets should go from that custom IP and can't go
through the kernel because of performance issue.
Ethernet core have own DMA which I could use but the question is if there is any
option how to convince the kernel that data will go directly from memory mapped
registers and the kernel/driver/... just setup dma BD for headers and second for
data.
Do you have any experience with any solution with passing data completely out of
kernel?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: Testing IRDA device driver
From: Amit Virdi @ 2011-04-19 10:14 UTC (permalink / raw)
To: samuel, davem, eric.dumazet; +Cc: Amit Virdi, netdev
In-Reply-To: <4DA830EF.701@st.com>
Hey,
I have been trying to transfer a file from one system to another using
IrCOMM layer on IrDA. We have a DICE's Fast IrDA Controller on our board
and I've written driver for the same. I need your help in
finding/resolving the problem, please.
In my setup, I'm using two identical boards having the IrDA IP logic.
Once the board is up, I'm executing two commands:
1. ifconfig irda0 up
2. echo 1 > /proc/sys/net/irda/discovery
Both the IrDA devices discover each other successfully. If I run
irattach, I can see SNRM command being sent and its response being
received on one board. Then some more messages are exchanged- i:cmd,
i:rsp, rr:cmd etc. I could see QOS parameters being exchanged. However,
after this rr:cmd and rr:rsp messages are exchanged for sometime and
then I get "IrLAP, no activity on link!" messages. No more messages are
exchanged thereafter.I took the irdadump logs for both the transmitter
and receiver. All the messages sent by the transmitter are received
successfully.
Meanwhile, when the rr:cmd rr:rsp messages are being exchanged, I tried
using ircp to transfer/receive file, but received an error message
"Connecting...failed". Could you please help me? I'm really bogged down
by this problem. I've been trying hard for the past couple of weeks. I
shall be very much thankful to you.
Best Regards
Amit Virdi
On 4/15/2011 5:20 PM, Amit Virdi wrote:
> Hi All/Samuel,
>
> I need your help in transferring file through IrCOMM layer.
>
> I'm facing a strange problem. I'm using same kernel image on two
> similar boards. When I run irattach /dev/ircomm0 on one board, the
> DISCOVERY protocol is initiated and the IrDA devices on both the
> boards detect each other. When irattach is run on board 2 also, SNRM
> command is sent by board 2 and UA response is received by it. After
> few more commands, "sirdev_receive too early" message is displayed
> multiple times and then "IrLAP, no activity on the link" message is
> received. The subsequent DISCOVERY REQUEST/RESPONSE does not have the
> hint field as c404 but 4400. If I run ircp -r on one board or ircp
> <filename>, I get "Connecting... failed" message.
>
> Is anyone having a clue what might be the problem?Here's the detailed
> description of the scenario:
> 1. When the boards are booted up, I run ifconfig irda0 up on both the
> boards. The port is up, no IrDA message is exchanged.
> 2. I run "irattach /dev/ircomm0 -s" on board 1. IrDA discovery
> protocol is initiated, XID command is sent and XID response is
> received. irdadump utility shows the messages exchanged.
> =============
> root@driver_s320:~# irattach /dev/ircomm0 -s &
> [2] 1456
> root@driver_s320:~# 00:02:08.167760 (37538.46 ms) xid:cmd f41be1cd >
> ffffffff S=6 s=0 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 00 00
> 00:02:08.261248 (0093.49 ms) xid:cmd f41be1cd > ffffffff S=6 s=1 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 01 00
> 00:02:08.361205 (0099.96 ms) xid:cmd f41be1cd > ffffffff S=6 s=2 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 02 00
> 00:02:08.362522 (0001.32 ms) xid:rsp f41be1cd < 0c4619da S=6 s=2 Linux
> hint=4400 [ Computer LAN Access ] (21)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 02 00 44 00
> 4c 69 6e 75 78
> 00:02:08.461210 (0098.69 ms) xid:cmd f41be1cd > ffffffff S=6 s=3 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 03 00
> 00:02:08.561216 (0100.01 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:02:08.661216 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=5 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 05 00
> 00:02:08.761269 (0100.05 ms) xid:cmd f41be1cd > ffffffff S=6 s=* Linux
> hint=c404 [ Computer LAN Access IrCOMM ] (22)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 ff 00 c4 04
> 00 4c 69 6e 75 78
> 00:02:12.351472 (3590.20 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:02:12.351818 (0000.35 ms) xid:cmd f41be1cd > ffffffff S=6 s=0 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 00 00
> 00:02:12.451344 (0099.53 ms) xid:cmd f41be1cd > ffffffff S=6 s=1 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 01 00
> 00:02:12.551376 (0100.03 ms) xid:cmd f41be1cd > ffffffff S=6 s=2 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 02 00
> 00:02:12.651354 (0099.98 ms) xid:cmd f41be1cd > ffffffff S=6 s=3 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 03 00
> 00:02:12.751354 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:02:12.752730 (0001.38 ms) xid:rsp f41be1cd < 0c4619da S=6 s=4 Linux
> hint=4400 [ Computer LAN Access ] (21)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 04 00 44 00
> 4c 69 6e 75 78
> =============
> 3. cat /proc/net/irda/discovery shows the output
> root@driver_s320:~# cat /proc/net/irda/discovery
> IrLMP: Discovery log:
>
> nickname: Linux, hint: 0x4400, saddr: 0xf41be1cd, daddr: 0x0c4619da
>
> 4. I run irattach /dev/ircomm0 -s on board 2 also
> 5. As a result, board 1 receives SNRM command. It sends the UA
> response. However, it receives "sirdev_write_complete - schedule speed
> change failed: -11" error multiple times.
> =======================
> 00:04:27.510549 (2114.77 ms) snrm:cmd ca=fe pf=1 f41be1cd < 0c4619da
> new-ca=f4
> LAP QoS: Baud Rate=9600bps Max Turn Time=500ms Data Size=2048B
> Window Size=7 Add BOFS=0 Min Turn Time=10000us Link Disc=12s (32)
> ff 93 da 19 46 0c cd e1 1b f4 f4 01 01 02 82 01
> 01 83 01 3f 84 01 7f 85 01 ff 86 01 01 08 01 07
> 00:04:27.512138 (0001.59 ms) ua:rsp ca=f4 pf=1 f41be1cd > 0c4619da
> LAP QoS: Baud Rate=9600bps Max Turn Time=500ms Data Size=2048B
> Window Size=7 Add BOFS=0 Min Turn Time=10000us Link Disc=12s (31)
> f4 73 cd e1 1b f4 da 19 46 0c 01 01 02 82 01 01
> 83 01 3f 84 01 7f 85 01 ff 86 01 01 08 01 07
> 00:04:27.613760 (0101.62 ms) rr:cmd < ca=f4 pf=1 nr=0 (2)
> f5 11
> 00:04:27.613952 (0000.19 ms) rr:rsp > ca=f4 pf=1
> nrsirdev_write_complete - schedule speed change failed: -11
> =0 (2)
> f4 11 sirdev_write_complete - schedule speed change failed: -11
>
> 00:04:27.61460sirdev_write_complete - schedule speed change failed: -11
> 2 (0000.65 ms) isirdev_write_complete - schedule speed change failed: -11
> :cmd < ca=f4 pfsirdev_write_complete - schedule speed change failed: -11
> =1 nr=0 ns=0 LM sirdev_write_complete - schedule speed change failed: -11
> slsap=12 dlsap=0sirdev_write_complete - schedule speed change failed: -11
> sirdev_write_complete - schedule speed change failed: -11
>
> f5 10 80 12 01sirdev_write_complete - schedule speed change
> failed: -11
> 00
> 00:04:27.615866 (0001.26 ms) i:rsp > ca=f4 pf=1 nr=1 ns=0 LM slsap=00
> dlsap=12 CONN_RSP (6)
> f4 30 92 00 81 00
> =======================
> 6. Board 2 receives following error messages.
> sirdev_receive - too early: c79e5026 / 30!
>
> 7. Few more messages are exchanged
> =======================
> 00:04:27.615866 (0001.26 ms) i:rsp > ca=f4 pf=1 nr=1 ns=0 LM slsap=00
> dlsap=12 CONN_RSP (6)
> f4 30 92 00 81 00
> 00:04:27.617376 (0001.51 ms) i:cmd < ca=f4 pf=1 nr=1 ns=1 LM slsap=12
> dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28)
> f5 32 00 12 84 0b 49 72 44 41 3a 49 72 43 4f 4d
> 4d 0a 50 61 72 61 6d 65 74 65 72 73
> 00:04:27.617978 (0000.60 ms) i:rsp > ca=f4 pf=1 nr=2 ns=1 LM slsap=00
> dlsap=12 GET_VALUE_BY_CLASS: Success
> IrCOMM Parameters Service Type=NINE_WIRE THREE_WIRE Port Type=N/A
> (19)
> f4 52 12 00 84 00 00 01 23 43 02 00 06 00 01 06
> 01 01 00
> 00:04:27.620832 (0002.85 ms) i:cmd < ca=f4 pf=0 nr=2 ns=2 LM slsap=12
> dlsap=00 DISC (6)
> f5 44 80 12 02 01
> 00:04:27.621237 (0000.41 ms) i:cmd < ca=f4 pf=1 nr=2 ns=3 LM slsap=13
> dlsap=00 CONN_CMD (6)
> f5 56 80 13 01 00
> 00:04:27.622725 (0001.49 ms) i:rsp > ca=f4 pf=1 nr=4 ns=2 LM slsap=00
> dlsap=13 CONN_RSP (6)
> f4 94 93 00 81 00
> 00:04:27.624464 (0001.74 ms) i:cmd < ca=f4 pf=1 nr=3 ns=4 LM slsap=13
> dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
> f5 78 00 13 84 0b 49 72 44 41 3a 49 72 43 4f 4d
> 4d 13 49 72 44 41 3a 54 69 6e 79 54 50 3a 4c 73
> 00:04:27.625088 (0000.62 ms) i:rsp > ca=f4 pf=1 nr=5 ns=3 LM slsap=00
> dlsap=13 GET_VALUE_BY_CLASS: Success Integer: 11 (15)
> f4 b6 13 00 84 00 00 01 23 43 01 00 00 00 11
> 00:04:27.627525 (0002.44 ms) i:cmd < ca=f4 pf=0 nr=4 ns=5 LM slsap=13
> dlsap=00 DISC (6)
> f5 8a 80 13 02 01
> 00:04:27.628016 (0000.49 ms) i:cmd < ca=f4 pf=1 nr=4 ns=6 LM slsap=11
> dlsap=11 CONN_CMD TTP credits=16 (7)
> f5 9c 91 11 01 00 10
> 00:04:27.629957 (0001.94 ms) i:rsp > ca=f4 pf=1 nr=7 ns=4 LM slsap=11
> dlsap=11 CONN_RSP TTP credits=16 (7)
> f4 f8 91 11 81 00 10
> 00:04:27.633168 (0003.21 ms) i:cmd < ca=f4 pf=1 nr=5 ns=7 LM slsap=11
> dlsap=11 TTP credits=0
> IrCOMM Service Type=NINE_WIRE Data Rate=9600 Data Format=13 Flow
> Control=00 DTEline State=0c (24)
> f5 be 11 11 00 12 00 01 04 10 04 00 00 25 80 11
> 01 13 12 01 00 20 01 0c
> 00:04:27.634586 (0001.42 ms) rr:rsp > ca=f4 pf=1 nr=0 (2)
> f4 11
> 00:04:27.642005 (0007.42 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:27.648576 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=2 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02 00
> 00:04:27.655098 (0006.52 ms) xid:cmd f168e953 > ffffffff S=6 s=3 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03 00
> 00:04:27.661669 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=4 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04 00
> 00:04:27.668240 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=5 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05 00
> 00:04:27.674762 (0006.52 ms) xid:cmd f168e953 > ffffffff S=6 s=*
> driver_s320 hint=c404 [ Computer LAN Access IrCOMM ] (28)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 ff 00 c4 04
> 00 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:27.681333 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:04:27.687904 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:27.806010 (0118.11 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:04:28.133157 (0327.15 ms) rr:cmd < ca=f4 pf=1 nr=5 (2)
> f5 b1
> 00:04:28.133402 (0000.25 ms) i:rsp > ca=f4 pf=0 nr=0 ns=5 LM slsap=11
> dlsap=11 TTP credits=1
> IrCOMM Data Rate=9600 Data Format=13 Flow Control=00 DTEline
> State=0c (21)
> f4 0a 11 11 01 0f 10 04 00 00 25 80 11 01 13 12
> 01 00 20 01 0c
> 00:04:28.134314 (0000.91 ms) i:rsp > ca=f4 pf=0 nr=0 ns=6 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0c 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00
> 00:04:28.135557 (0001.24 ms) i:rsp > ca=f4 pf=0 nr=0 ns=7 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0e 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01
> 00:04:28.136298 (0000.74 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:28.136645 (0000.35 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.136912 (0000.27 ms) xid:cmd f168e953 > ffffffff S=6 s=2 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02 00
> 00:04:28.137413 (0000.50 ms) xid:cmd f168e953 > ffffffff S=6 s=3 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03 00
> 00:04:28.137738 (0000.32 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.138832 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.139898 (0001.07 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
> 00:04:28.141216 (0001.32 ms) rr:cmd < ca=f4 pf=1 nr=7 (2)
> f5 f1
> 00:04:28.141370 (0000.15 ms) i:rsp > ca=f4 pf=0 nr=0 ns=7 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0e 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01
> 00:04:28.142453 (0001.08 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.143541 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.144629 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.145765 (0001.14 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
> 00:04:28.147157 (0001.39 ms) rr:cmd < ca=f4 pf=1 nr=0 (2)
> f5 11
> 00:04:28.147322 (0000.17 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.148405 (0001.08 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.149498 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.150581 (0001.08 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
>
> 8. In between the board 1 sends few XID commands with changed HW address.
> 00:04:28.165952 (0015.37 ms) xid:cmd f168e953 > ffffffff S=6 s=4 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04 00
> 00:04:28.255925 (0089.97 ms) xid:cmd f168e953 > ffffffff S=6 s=5 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05 00
> 00:04:28.345898 (0089.97 ms) xid:cmd f168e953 > ffffffff S=6 s=*
> driver_s320 hint=c404 [ Computer LAN Access IrCOMM ] (28)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 ff 00 c4 04
> 00 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:30.816069 (2470.17 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
>
> 9. Then few logs of no activity on the link are received:
> IrLAP, no activity on link!
> IrLAP, no activity on link!
> IrLAP, no activity on link!
> IrLAP, no activity on link!
>
> 10. The board 1 again sends XID commands with *original* HW address.
> Board 2 also sends the XID commands
> 11. XID response is sent by both the boards to each other. Now, the
> hint field is not c404 but 4400. hint becomes c404 when we run
> irattach /dev/ircomm0. Before that it is 4400 (by default)
> ==================
> 00:04:58.208341 (0001.47 ms) xid:rsp f41be1cd < 0c4619da S=6 s=3
> driver_s310 hint=4400 [ Computer LAN Access ] (27)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 03 00 44 00
> 64 72 69 76 65 72 5f 73 33 31 30
> 00:04:58.306869 (0098.53 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:04:58.406874 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=5 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 05 00
> 00:04:58.506880 (0100.01 ms) xid:cmd f41be1cd > ffffffff S=6 s=*
> driver_s320 hint=4400 [ Computer LAN Access ] (27)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 ff 00 44 00
> 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:58.744384 (0237.50 ms) xid:cmd ffffffff < 0c4619da S=6 s=0 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 00 00
> 00:04:58.844277 (0099.89 ms) xid:cmd ffffffff < 0c4619da S=6 s=1 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 01 00
> 00:04:58.944277 (0100.00 ms) xid:cmd ffffffff < 0c4619da S=6 s=2 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 02 00
> 00:04:58.944485 (0000.21 ms) xid:rsp f41be1cd > 0c4619da S=6 s=2
> driver_s320 hint=4400 [ Computer LAN Access ] (27)
> fe bf 01 cd e1 1b f4 da 19 46 0c 01 02 00 44 00
> 64 72 69 76 65 72 5f 73 33 32 30
> ==================
> 12. cat /proc/net/irda/discovery shows the following output.
> ==================
> root@driver_s320:~# cat /proc/net/irda/discovery
> IrLMP: Discovery log:
>
> nickname: driver_s310, hint: 0x4400, saddr: 0xf41be1cd, daddr: 0x0c4619da
> ==================
> 13. The above XID CMD/RSP sequence goes on and on.
>
> I shall be very much thankful for any support
>
> ~Amit Virdi
>
> On 4/13/2011 12:10 PM, Amit Virdi wrote:
>> Hi All,
>>
>> For the past few days I've been trying to test a driver that I've
>> written for DICE Fast IrDA controller. As per my requirements, I need
>> to use IrCOMM as the upper layer.
>>
>> I'm using the same kernel image on the both the boards. When I run
>> irattach on either of the boards I can see discovery protocol being
>> initiated and completing successfully (cat /proc/net/irda/discovery
>> giving output with other ends's device's MAC address as the daddr)
>> but I'm struggling to test the driver further.
>>
>> I've observed that the discovery request/response sequence goes on
>> for 5 minutes. After this, the discovery process stops. On the master
>> side, I could see no IrLAP frame being sent/received and also the
>> output of cat /proc/net/irda/discovery is NULL. However, on the slave
>> side, the cat /proc/net/irda/discovery output shows the master side!!
>>
>> If I run irattach on the slave side also, no DISCOVERY message is
>> exchanged and then, the output of slave side also doesn't show anything.
>>
>> Sometimes, I start getting log "IrLAP, no activity on link!" and then
>> ircomm_close() API is called from within the stack.
>>
>> If, I try to run getty on /dev/ircomm0, it does not work!
>>
>> If I try to transfer data using
>> echo "1234567890" > /dev/ircomm0
>> on the master side, and
>> cat /dev/ircomm0
>> on the slave side, I can see SNRM command, UA response, RR command,
>> IrLMP connect/disconnect etc. However, the data transfer actually
>> didn't happen. I cannot see the string "1234567890" on the slave side.
>>
>> Please suggest what I'm missing/doing wrong. I need to transfer data
>> from one device to another to complete the testing. I shall be very
>> much thankful for suggestions/advice.
>>
>> Thanks n Regards
>> Amit Virdi
^ permalink raw reply
* Re: [PATCH 17/34] hdlcdrv: Drop __TIME__ usage
From: walter harms @ 2011-04-19 10:17 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-kbuild, Thomas Sailer, linux-hams, netdev
In-Reply-To: <1302015561-21047-18-git-send-email-mmarek@suse.cz>
Am 05.04.2011 16:59, schrieb Michal Marek:
> The kernel already prints its build timestamp during boot, no need to
> repeat it in random drivers and produce different object files each
> time.
>
> Cc: Thomas Sailer <t.sailer@alumni.ethz.ch>
> Cc: linux-hams@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Michal Marek <mmarek@suse.cz>
> ---
> drivers/net/hamradio/hdlcdrv.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
> index 5b37579..a4a3516 100644
> --- a/drivers/net/hamradio/hdlcdrv.c
> +++ b/drivers/net/hamradio/hdlcdrv.c
> @@ -749,7 +749,7 @@ EXPORT_SYMBOL(hdlcdrv_unregister);
> static int __init hdlcdrv_init_driver(void)
> {
> printk(KERN_INFO "hdlcdrv: (C) 1996-2000 Thomas Sailer HB9JNX/AE4WA\n");
> - printk(KERN_INFO "hdlcdrv: version 0.8 compiled " __TIME__ " " __DATE__ "\n");
> + printk(KERN_INFO "hdlcdrv: version 0.8\n");
> return 0;
> }
>
Its a bit late but i am not a big fan of hard coded version id's.
Does GIT provide something like that ? If not
IMHO the line
printk(KERN_INFO "hdlcdrv: version 0.8\n");
can be removed.
re,
wh
^ permalink raw reply
* Re: Add NAPI support to ll_temac driver
From: Eric Dumazet @ 2011-04-19 10:43 UTC (permalink / raw)
To: monstr; +Cc: netdev
In-Reply-To: <4DAD5753.4040108@monstr.eu>
Le mardi 19 avril 2011 à 11:35 +0200, Michal Simek a écrit :
> Hi,
>
> I would like to try to add NAPI support for ll_temac and look if help us to
> improve performance on Microblaze system. I would expect that bandwidth should
> be increased.
> We have the second non mainline driver which use tasklets and it provides better
> performance than mainline driver but not so big that's why I think that NAPI
> can increase performance.
>
> Can you please point me to any driver which I could use as a template?
> Or any developer guide to do so.
>
> Do you know any other option how to improve driver performance on low speed cpu?
>
> I have found that driver spends a lot of time on skb allocation and preallocated
> SKBs help a little bit. I have done a test where I increased number of
> preallocated BDs(SKBs) for rx to 35000 and disable new BD(SKB) allocation in
> rx_irq. 35000 BDs is setup because I need them to successfully finish netperf
> test. I have got 25% bandwidth increasing.
>
> It will be also nice to be able to allocate several BDs(SKBs) which could be
> faster than allocate them in sequence.
Depends if your cpu has some cache. The best performance is to try to
get high cache hit ratios.
One possible way to get better performance is to change driver to
allocate skbs only right before calling netif_rx(), so that you dont
have to access cold sk_buff data twice (once when allocating skb and put
it in ring buffer, a second time when receiving frame)
drivers/net/niu.c is a good example for this (NAPI + netdev_alloc_skb()
just in time + pull in skbhead only first cache line of packet)
drivers/net/ftmac100.c is also a recent driver (and probably a better
start with less complex hardware than NIU) using these tricks
{ skb = netdev_alloc_skb_ip_align(netdev, 128);
__pskb_pull_tail(skb, min(length, 64));
}
^ permalink raw reply
* [PATCH] net: infiniband/ulp/ipoib: convert to hw_features
From: Michał Mirosław @ 2011-04-19 10:43 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Michał Mirosław <mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 1 -
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 11 +--------
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 28 --------------------------
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 26 ++++++++++++++++-------
5 files changed, 21 insertions(+), 47 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index ab97f92..7b6985a 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -91,7 +91,6 @@ enum {
IPOIB_STOP_REAPER = 7,
IPOIB_FLAG_ADMIN_CM = 9,
IPOIB_FLAG_UMCAST = 10,
- IPOIB_FLAG_CSUM = 11,
IPOIB_MAX_BACKOFF_SECONDS = 16,
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 93d5580..39913a0 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1463,8 +1463,7 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
set_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
ipoib_warn(priv, "enabling connected mode "
"will cause multicast packet drops\n");
-
- dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO);
+ netdev_update_features(dev);
rtnl_unlock();
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
@@ -1474,13 +1473,7 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
if (!strcmp(buf, "datagram\n")) {
clear_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
-
- if (test_bit(IPOIB_FLAG_CSUM, &priv->flags)) {
- dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- priv->dev->features |= NETIF_F_GRO;
- if (priv->hca_caps & IB_DEVICE_UD_TSO)
- dev->features |= NETIF_F_TSO;
- }
+ netdev_update_features(dev);
dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
index 19f7f52..29bc7b5 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
@@ -42,32 +42,6 @@ static void ipoib_get_drvinfo(struct net_device *netdev,
strncpy(drvinfo->driver, "ipoib", sizeof(drvinfo->driver) - 1);
}
-static u32 ipoib_get_rx_csum(struct net_device *dev)
-{
- struct ipoib_dev_priv *priv = netdev_priv(dev);
- return test_bit(IPOIB_FLAG_CSUM, &priv->flags) &&
- !test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
-}
-
-static int ipoib_set_tso(struct net_device *dev, u32 data)
-{
- struct ipoib_dev_priv *priv = netdev_priv(dev);
-
- if (data) {
- if (!test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags) &&
- (dev->features & NETIF_F_SG) &&
- (priv->hca_caps & IB_DEVICE_UD_TSO)) {
- dev->features |= NETIF_F_TSO;
- } else {
- ipoib_warn(priv, "can't set TSO on\n");
- return -EOPNOTSUPP;
- }
- } else
- dev->features &= ~NETIF_F_TSO;
-
- return 0;
-}
-
static int ipoib_get_coalesce(struct net_device *dev,
struct ethtool_coalesce *coal)
{
@@ -108,8 +82,6 @@ static int ipoib_set_coalesce(struct net_device *dev,
static const struct ethtool_ops ipoib_ethtool_ops = {
.get_drvinfo = ipoib_get_drvinfo,
- .get_rx_csum = ipoib_get_rx_csum,
- .set_tso = ipoib_set_tso,
.get_coalesce = ipoib_get_coalesce,
.set_coalesce = ipoib_set_coalesce,
};
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 806d029..81ae61d 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -292,7 +292,7 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
dev->stats.rx_bytes += skb->len;
skb->dev = dev;
- if (test_bit(IPOIB_FLAG_CSUM, &priv->flags) && likely(wc->csum_ok))
+ if ((dev->features & NETIF_F_RXCSUM) && likely(wc->csum_ok))
skb->ip_summed = CHECKSUM_UNNECESSARY;
napi_gro_receive(&priv->napi, skb);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index aca3b44..86addca 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -171,6 +171,16 @@ static int ipoib_stop(struct net_device *dev)
return 0;
}
+static u32 ipoib_fix_features(struct net_device *dev, u32 features)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+
+ if (test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags))
+ features &= ~(NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO);
+
+ return features;
+}
+
static int ipoib_change_mtu(struct net_device *dev, int new_mtu)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -970,6 +980,7 @@ static const struct net_device_ops ipoib_netdev_ops = {
.ndo_open = ipoib_open,
.ndo_stop = ipoib_stop,
.ndo_change_mtu = ipoib_change_mtu,
+ .ndo_fix_features = ipoib_fix_features,
.ndo_start_xmit = ipoib_start_xmit,
.ndo_tx_timeout = ipoib_timeout,
.ndo_set_multicast_list = ipoib_set_mcast_list,
@@ -1154,19 +1165,18 @@ int ipoib_set_dev_features(struct ipoib_dev_priv *priv, struct ib_device *hca)
kfree(device_attr);
if (priv->hca_caps & IB_DEVICE_UD_IP_CSUM) {
- set_bit(IPOIB_FLAG_CSUM, &priv->flags);
- priv->dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM;
+ priv->dev->hw_features = NETIF_F_SG |
+ NETIF_F_IP_CSUM | NETIF_F_RXCSUM;
+
+ if (priv->hca_caps & IB_DEVICE_UD_TSO)
+ priv->dev->hw_features |= NETIF_F_TSO;
+
+ priv->dev->features |= priv->dev->hw_features;
}
- priv->dev->features |= NETIF_F_GRO;
-
- if (priv->dev->features & NETIF_F_SG && priv->hca_caps & IB_DEVICE_UD_TSO)
- priv->dev->features |= NETIF_F_TSO;
-
return 0;
}
-
static struct net_device *ipoib_add_port(const char *format,
struct ib_device *hca, u8 port)
{
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] net: dsa: remove ethtool_ops->set_sg
From: Michał Mirosław @ 2011-04-19 10:43 UTC (permalink / raw)
To: netdev
Remove set_sg from DSA slave ethtool_ops. Features inheritance looks
broken/not fully implemented anyway.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/dsa/slave.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 64ca2a6..0a47b6c 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -288,7 +288,6 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_drvinfo = dsa_slave_get_drvinfo,
.nway_reset = dsa_slave_nway_reset,
.get_link = dsa_slave_get_link,
- .set_sg = ethtool_op_set_sg,
.get_strings = dsa_slave_get_strings,
.get_ethtool_stats = dsa_slave_get_ethtool_stats,
.get_sset_count = dsa_slave_get_sset_count,
--
1.7.2.5
^ permalink raw reply related
* [PATCH] Staging: convert hv network driver to hw_features
From: Michał Mirosław @ 2011-04-19 10:43 UTC (permalink / raw)
To: netdev
Cc: Greg Kroah-Hartman, Hank Janssen, Haiyang Zhang, K. Y. Srinivasan,
Abhishek Kane, devel
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/staging/hv/netvsc_drv.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/staging/hv/netvsc_drv.c
index 3397356..aaa8188 100644
--- a/drivers/staging/hv/netvsc_drv.c
+++ b/drivers/staging/hv/netvsc_drv.c
@@ -317,8 +317,6 @@ static void netvsc_get_drvinfo(struct net_device *net,
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo = netvsc_get_drvinfo,
- .get_sg = ethtool_op_get_sg,
- .set_sg = ethtool_op_set_sg,
.get_link = ethtool_op_get_link,
};
@@ -406,6 +404,7 @@ static int netvsc_probe(struct device *device)
net->netdev_ops = &device_ops;
/* TODO: Add GSO and Checksum offload */
+ net->hw_features = NETIF_F_SG;
net->features = NETIF_F_SG;
SET_ETHTOOL_OPS(net, ðtool_ops);
--
1.7.2.5
^ permalink raw reply related
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