* Re: [PATCH net-next 1/2] mlx4_core: fix mtt range deallocation
From: Yinghai Lu @ 2012-01-02 22:05 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev, marcela
In-Reply-To: <4F01BA2B.1060605@mellanox.co.il>
On Mon, Jan 2, 2012 at 6:07 AM, Yevgeny Petrilin
<yevgenyp@mellanox.co.il> wrote:
> From: Marcel Apfelbaum <marcela@mellanox.co.il>
>
> The mtt range was allocated in mtt units but deallocated
> in segments. Among the rest, this caused crash during hotplug removal
>
> Reported-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
> Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> ---
> drivers/net/ethernet/mellanox/mlx4/mr.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
> index f7243b2..01df556 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mr.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
> @@ -239,8 +239,8 @@ void __mlx4_free_mtt_range(struct mlx4_dev *dev, u32 offset, int order)
> first_seg = offset / (1 << log_mtts_per_seg);
>
> mlx4_buddy_free(&mr_table->mtt_buddy, first_seg, seg_order);
> - mlx4_table_put_range(dev, &mr_table->mtt_table, first_seg,
> - first_seg + (1 << seg_order) - 1);
> + mlx4_table_put_range(dev, &mr_table->mtt_table, offset,
> + offset + (1 << order) - 1);
> }
>
> static void mlx4_free_mtt_range(struct mlx4_dev *dev, u32 offset, int order)
Tested-by: Yinghai Lu <yinghai@kernel.org>
^ permalink raw reply
* Re: [PATCH] sch_qfq: fix overflow in qfq_update_start()
From: Dave Taht @ 2012-01-02 21:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Stephen Hemminger
In-Reply-To: <1325540706.2874.3.camel@edumazet-laptop>
On Mon, Jan 2, 2012 at 10:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 02 janvier 2012 à 16:47 +0100, Eric Dumazet a écrit :
>> grp->slot_shift is between 22 and 41, so using 32bit wide variables is
>> probably a typo.
>>
>> This could explain QFQ hangs Dave reported to me, after 2^23 packets ?
>>
>> (23 = 64 - 41)
>>
>> Reported-by: Dave Taht <dave.taht@gmail.com>
>> CC: Stephen Hemminger <shemminger@vyatta.com>
>> CC: Dave Taht <dave.taht@gmail.com>
>
> Oh well, I forgot my SOB :(
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> David please just tell me if you prefer me to resend it
>
>
I figure I'm the wrong david, but I'll be testing the QFQ patch overnight.
I have tested it for about an hour thus far.
Your SFQ patch, posted earlier today, does bring SFQ and QFQ back
into equivalence at 10 iperfs.
http://www.teklibre.com/~d/bloat/sfqnewvsqfq10iperfs.png
Well done.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* [PATCH net-next] sch_qfq: accurate wsum handling
From: Eric Dumazet @ 2012-01-02 21:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger
We can underestimate q->wsum in case of "tc class replace ... qfq"
and/or qdisc_create_dflt() error.
wsum is not really used in fast path, only at qfq qdisc/class setup,
to catch user error.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
---
net/sched/sch_qfq.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 1033434..2c5ff61 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -211,6 +211,7 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
struct nlattr *tb[TCA_QFQ_MAX + 1];
u32 weight, lmax, inv_w;
int i, err;
+ int delta_w;
if (tca[TCA_OPTIONS] == NULL) {
pr_notice("qfq: no options\n");
@@ -232,9 +233,10 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
inv_w = ONE_FP / weight;
weight = ONE_FP / inv_w;
- if (q->wsum + weight > QFQ_MAX_WSUM) {
+ delta_w = weight - (cl ? ONE_FP / cl->inv_w : 0);
+ if (q->wsum + delta_w > QFQ_MAX_WSUM) {
pr_notice("qfq: total weight out of range (%u + %u)\n",
- weight, q->wsum);
+ delta_w, q->wsum);
return -EINVAL;
}
@@ -256,13 +258,12 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
return err;
}
- sch_tree_lock(sch);
- if (tb[TCA_QFQ_WEIGHT]) {
- q->wsum = weight - ONE_FP / cl->inv_w;
+ if (inv_w != cl->inv_w) {
+ sch_tree_lock(sch);
+ q->wsum += delta_w;
cl->inv_w = inv_w;
+ sch_tree_unlock(sch);
}
- sch_tree_unlock(sch);
-
return 0;
}
@@ -277,7 +278,6 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
i = qfq_calc_index(cl->inv_w, cl->lmax);
cl->grp = &q->groups[i];
- q->wsum += weight;
cl->qdisc = qdisc_create_dflt(sch->dev_queue,
&pfifo_qdisc_ops, classid);
@@ -294,6 +294,7 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
return err;
}
}
+ q->wsum += weight;
sch_tree_lock(sch);
qdisc_class_hash_insert(&q->clhash, &cl->common);
^ permalink raw reply related
* Re: [ANNOUNCE] libnetfilter_queue 1.0.1 release
From: Pablo Neira Ayuso @ 2012-01-02 21:45 UTC (permalink / raw)
To: Jan Engelhardt
Cc: netfilter, netdev, netfilter-devel, netfilter-announce, lwn
In-Reply-To: <alpine.LNX.2.01.1201022221470.29809@frira.zrqbmnf.qr>
On Mon, Jan 02, 2012 at 10:22:28PM +0100, Jan Engelhardt wrote:
> On Monday 2012-01-02 20:58, Pablo Neira Ayuso wrote:
>
> >Hi!
> >
> >The Netfilter project proudly presents:
> >
> > libnetfilter_queue 1.0.1
>
> In commit 390b0c0f45597c72fa93a40f4f7f9ffeec371f42
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon Jan 2 20:28:45 2012 +0100
>
> build: bump version to 1.0.1
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0bd037f..bc27625 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -18,7 +18,7 @@
> # set age to 0.
> # </snippet>
> #
> -LIBVERSION=2:0:1
> +LIBVERSION=2:0:2
>
> include ${top_srcdir}/Make_global.am
>
>
> You wrongly changed LIBVERSION. It went from .so.1.1 to so.0.2, and that
> just does not sound right. Perhaps you intended 2:1:1.
>
> Or just leaving r alone, like proposed? :)
I forgot to increment current, Florian Westphal added some new
interfaces. I'll fix this, sorry.
^ permalink raw reply
* Re: [PATCH] sch_qfq: fix overflow in qfq_update_start()
From: Eric Dumazet @ 2012-01-02 21:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger, Dave Taht
In-Reply-To: <1325519277.2375.24.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le lundi 02 janvier 2012 à 16:47 +0100, Eric Dumazet a écrit :
> grp->slot_shift is between 22 and 41, so using 32bit wide variables is
> probably a typo.
>
> This could explain QFQ hangs Dave reported to me, after 2^23 packets ?
>
> (23 = 64 - 41)
>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> CC: Dave Taht <dave.taht@gmail.com>
Oh well, I forgot my SOB :(
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
David please just tell me if you prefer me to resend it
^ permalink raw reply
* Re: [ANNOUNCE] libnetfilter_queue 1.0.1 release
From: Jan Engelhardt @ 2012-01-02 21:40 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter, netdev, netfilter-devel, netfilter-announce, lwn
In-Reply-To: <alpine.LNX.2.01.1201022221470.29809@frira.zrqbmnf.qr>
On Monday 2012-01-02 22:22, Jan Engelhardt wrote:
>On Monday 2012-01-02 20:58, Pablo Neira Ayuso wrote:
>
>>Hi!
>>
>>The Netfilter project proudly presents:
>>
>> libnetfilter_queue 1.0.1
>
>In commit 390b0c0f45597c72fa93a40f4f7f9ffeec371f42
>Author: Pablo Neira Ayuso <pablo@netfilter.org>
>Date: Mon Jan 2 20:28:45 2012 +0100
>
> build: bump version to 1.0.1
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
>diff --git a/src/Makefile.am b/src/Makefile.am
>index 0bd037f..bc27625 100644
>--- a/src/Makefile.am
>+++ b/src/Makefile.am
>@@ -18,7 +18,7 @@
> # set age to 0.
> # </snippet>
> #
>-LIBVERSION=2:0:1
>+LIBVERSION=2:0:2
>
> include ${top_srcdir}/Make_global.am
>
>
>You wrongly changed LIBVERSION. It went from .so.1.1 to so.0.2, and that
>just does not sound right. Perhaps you intended 2:1:1.
>
>Or just leaving r alone, like proposed? :)
Upon closer review, you ought to select 3:0:2, since you added functions
since libnetfilter_queue-1.0.0.
===
origin git://dev.medozas.de/libnetfilter_queue master
parent 390b0c0f45597c72fa93a40f4f7f9ffeec371f42 (libnetfilter_queue-1.0.1)
commit a192d817a16ba08193a90043b46b6e2cf2d05091
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Mon Jan 2 22:36:03 2012 +0100
build: properly bump SO version
The last SO version update was bogus: 2:0:1 (.so.1.1.0) -> 2:0:2
(.so.0.2.0).
Since two functions were added between v1.0.0..v1.0.1, CURRENT needs
to be bumped at the least.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
src/Makefile.am | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index bc27625..d49e738 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -18,7 +18,7 @@
# set age to 0.
# </snippet>
#
-LIBVERSION=2:0:2
+LIBVERSION=3:0:2
include ${top_srcdir}/Make_global.am
--
# Created with git-export-patch
^ permalink raw reply related
* Re: [ANNOUNCE] libnetfilter_queue 1.0.1 release
From: Jan Engelhardt @ 2012-01-02 21:22 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter, netdev, netfilter-devel, netfilter-announce, lwn
In-Reply-To: <20120102195845.GA26867@1984>
On Monday 2012-01-02 20:58, Pablo Neira Ayuso wrote:
>Hi!
>
>The Netfilter project proudly presents:
>
> libnetfilter_queue 1.0.1
In commit 390b0c0f45597c72fa93a40f4f7f9ffeec371f42
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon Jan 2 20:28:45 2012 +0100
build: bump version to 1.0.1
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
diff --git a/src/Makefile.am b/src/Makefile.am
index 0bd037f..bc27625 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -18,7 +18,7 @@
# set age to 0.
# </snippet>
#
-LIBVERSION=2:0:1
+LIBVERSION=2:0:2
include ${top_srcdir}/Make_global.am
You wrongly changed LIBVERSION. It went from .so.1.1 to so.0.2, and that
just does not sound right. Perhaps you intended 2:1:1.
Or just leaving r alone, like proposed? :)
^ permalink raw reply related
* Re: [PATCH] r6040: use an unique MDIO bus name
From: David Miller @ 2012-01-02 20:49 UTC (permalink / raw)
To: florian; +Cc: netdev, vova.kolpakov
In-Reply-To: <1325497800-21450-1-git-send-email-florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 2 Jan 2012 10:50:00 +0100
> + snprintf(lp->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
> + dev_name(&pdev->dev), card_idx);
Please don't be so sloppy with the formatting like this,
make the arguments on the second line get indented exactly
to the first column after the openning parenthesis on the
first line.
If you can't be bothered to get this right by hand, use
something like emacs's C-mode to do it for you when you hit
TAB.
^ permalink raw reply
* [ANNOUNCE] libnetfilter_log 1.0.1 release
From: Pablo Neira Ayuso @ 2012-01-02 20:26 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi!
The Netfilter project proudly presents:
libnetfilter_log 1.0.1
libnetfilter_log is a userspace library providing interface to packets
that have been logged by the kernel packet filter.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_log/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_log/
Have fun!
[-- Attachment #2: changes-libnetfilter_log-1.0.1.txt --]
[-- Type: text/plain, Size: 1401 bytes --]
Jan Engelhardt (23):
build: use autoconf-suggested naming of files
build: use modern call syntax for AC_INIT, AM_INIT_AUTOMAKE
build: avoid use of deprecated INCLUDES
build: use simpler autoreconf in autogen
build: run AC_CANONICAL_HOST only
build: remove statements without effect
build: remove -fPIC flag
build: no need for error message in PKG_CHECK_MODULES
build: set Libs.private for pkgconfig file
Remove accidentally-added file "depcomp"
Add .gitignore files
build: default to not building static libraries
build: use AC_OUTPUT
src: remove redundant casts
src: declare non-modified data as const
build: remove unused LIBTOOL_DEPS
build: create a Make_global.am file
build: use -Wall across the entire source
utils: resolve compiler warnings
build: fix error with automake-1.9
Update .gitignore
build: use AC_CONFIG_AUX_DIR and stash away tools
build: disable implicit .tar.gz archive generation and use POSIX mode
Pablo Neira Ayuso (7):
build: bump version to 1.0.0
license: upgrade to GPLv2+
doc: discourage the use of nflog_set_nlbufsiz()
Merge branch 'master' of git://dev.medozas.de/libnetfilter_log
build: fix `make distcheck'
build: Linux kernel-style for compilation messages
build: bump version to 1.0.1
^ permalink raw reply
* Re: [ANNOUNCE] libnetfilter_queue 1.0.1 release
From: Pablo Neira Ayuso @ 2012-01-02 19:59 UTC (permalink / raw)
To: netfilter; +Cc: netdev, netfilter-devel, netfilter-announce, lwn
In-Reply-To: <20120102195845.GA26867@1984>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
On Mon, Jan 02, 2012 at 08:58:45PM +0100, Pablo Neira Ayuso wrote:
> Hi!
>
> The Netfilter project proudly presents:
>
> libnetfilter_queue 1.0.1
>
> libnetfilter_queue is a userspace library providing an API to packets
> that have been queued by the kernel packet filter.
>
> See ChangeLog that comes attached to this email for more details.
Forgot to attach, find it here.
[-- Attachment #2: changes-libnetfilter_queue-1.0.1.txt --]
[-- Type: text/plain, Size: 1755 bytes --]
Alessandro Vesely (1):
utils: document ENOBUFS in nfqnl_test.c
Florian Westphal (2):
src: add NFQNL_MSG_VERDICT_BATCH support
src: add notes on NF_STOLEN and NF_REPEAT to documentation
Jan Engelhardt (20):
build: build: use autoconf-suggested naming of files
build: use modern call syntax for AC_INIT, AM_INIT_AUTOMAKE
build: avoid use of deprecated INCLUDES
build: use simpler autoreconf in autogen
build: run AC_CANONICAL_HOST only
build: no need for error message in PKG_CHECK_MODULES
build: set Libs.private for pkgconfig file
build: remove statements without effect
build: remove -fPIC flag
Update .gitignore
build: default to not building static libraries
build: use AC_OUTPUT
build: remove unused LIBTOOL_DEPS
build: create a Make_global.am file
build: use -Wall across the entire source
build: fix error with automake-1.9
build: fix file list warning with automake-1.9
Update .gitignore
build: use AC_CONFIG_AUX_DIR and stash away tools
build: disable implicit .tar.gz archive generation and use POSIX mode
Pablo Neira Ayuso (11):
nfq: add missing documentation on nfq_snprintf_xml()
nfq: add myself to the copyright notice
nfq: fix redundant LIBVERSION definition
license: upgrade to GPLv2+
Merge branch 'master' of git://dev.medozas.de/libnetfilter_queue
doc: document some performance tweaks for libnetfilter_queue
Merge branch 'master' of git://dev.medozas.de/libnetfilter_queue
doc: fix wrong documentation on NFQNL_COPY_NONE
build: fix `make distcheck'
build: Linux kernel-style for compilation messages
build: bump version to 1.0.1
^ permalink raw reply
* [ANNOUNCE] libnetfilter_queue 1.0.1 release
From: Pablo Neira Ayuso @ 2012-01-02 19:58 UTC (permalink / raw)
To: netfilter; +Cc: netdev, netfilter-devel, netfilter-announce, lwn
Hi!
The Netfilter project proudly presents:
libnetfilter_queue 1.0.1
libnetfilter_queue is a userspace library providing an API to packets
that have been queued by the kernel packet filter.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_queue/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_queue/
Have fun!
^ permalink raw reply
* Re: [PATCH net-next] xfrm: Call IP receive handler directly for inbound tunnel-mode packets
From: Ward, David - 0663 - MITLL @ 2012-01-02 19:52 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120102072828.GA5380@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
Hi Herbert,
On 01/02/2012 02:28 AM, Herbert Xu wrote:
> On Sun, Jan 01, 2012 at 10:32:34PM -0500, David Ward wrote:
>> For IPsec tunnel mode (or BEET mode), after inbound packets are xfrm'ed,
>> call the IPv4/IPv6 receive handler directly instead of calling netif_rx.
>> In addition to avoiding unneeded re-processing of the MAC layer, packets
>> will not be received a second time on network taps. (Note that outbound
>> packets are only received on network taps post-xfrm, but inbound packets
>> were being received both pre- and post-xfrm. So now network taps will
>> receive packets in either direction only once, in the form that they go
>> "over the wire".)
>>
>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>> Cc: Herbert Xu<herbert@gondor.apana.org.au>
> You can't do this as this may cause stack overruns if we nest
> too deeply.
Sorry if I'm missing something, but how are such overruns avoided on the
outbound side?
> Changing the existing tap processing behaviour will also break
> existing setups.
Assuming there might be a better way to make this change, are there
examples of existing setups that would be negatively affected? From my
perspective this behavior is just an unintended artifact of xfrm'ed
packets being placed back into netif_rx, which only occurs for inbound
packets, and it complicates the usage of network taps on these
interfaces (i.e. how do you systematically determine whether any packet
is post-xfrm and was already seen in an earlier form?). It seems to me
that network taps operate at a lower layer than xfrm, and so xfrm should
be invisible to the network taps. If users are, for example, capturing
ESP packets from a PF_PACKET socket and want to examine the decrypted
payload, I think the capture application should be responsible for the
decryption, just as it would be at higher layers with something like
SSL/TLS (and again for example, both protocols can be decrypted by
Wireshark when provided the keys).
I would appreciate your feedback.
David
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4558 bytes --]
^ permalink raw reply
* Re: [BUG] SIOCSIFFLAGS returns -EIO on SMSC LAN911x
From: Ben Hutchings @ 2012-01-02 19:45 UTC (permalink / raw)
To: Javier Martinez Canillas; +Cc: netdev, Enric Balletbo i Serra
In-Reply-To: <CAAwP0s1KV0gCWXB4-sNDjyVKETGrp9xO8VmAnbJHHCupf4P5pg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
On Mon, 2012-01-02 at 19:37 +0100, Javier Martinez Canillas wrote:
[...]
> Thanks for your help.
>
> Finally, what I did was to bring to operational mode the integrated
> PHY chip by disabling the energy detect power-down mode before doing a
> software reset and re-enabling after it.
>
> Does that solution make sense to you? I've sent the patch-set to the
> list for review. The patch-set is composed of the following patches:
[...]
I think that if the data sheet says the power-down bit is reserved on
the 9221i then it is better not to set it at all. However, given that
you actually have hardware to test on, you are in a better position to
say what actually works.
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names taken.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [ANNOUNCE] libmnl 1.0.2 release
From: Pablo Neira Ayuso @ 2012-01-02 18:55 UTC (permalink / raw)
To: Netfilter Development Mailing list
Cc: netdev, netfilter, lwn, netfilter-announce
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
Hi!
The Netfilter project presents libmnl-1.0.0
libmnl is a minimalistic user-space library oriented to Netlink
developers. There are a lot of common tasks in parsing, validating,
constructing of both the Netlink header and TLVs that are repetitive
and
easy to get wrong. This library aims to provide simple helpers that
allows you to re-use code and to avoid re-inventing the wheel.
This library is released under LGPLv2+.
Features:
* Small: the shared library requires around 45KB for an x86-based
* computer.
* Simple: this library avoids complexity and elaborated abstractions
that tend to hide Netlink details.
* Easy to use: the library simplifies the work for Netlink-wise
developers. It provides functions to make socket handling, message
building, validating, parsing and sequence tracking, easier.
* Easy to re-use: you can use the library to build your own
* abstraction
layer on top of this library.
* Decoupling: the interdependency of the main bricks that compose the
library is reduced, i.e. the library provides many helpers, but the
programmer is not forced to use them.
More info at:
http://www.netfilter.org/projects/libmnl/
Doxygen documentation at:
http://www.netfilter.org/projects/libmnl/doxygen/
You can download it via FTP at:
ftp://ftp.netfilter.org/pub/libmnl
Enjoy!
[-- Attachment #2: changes-libmnl-1.0.2.txt --]
[-- Type: text/plain, Size: 1064 bytes --]
Jan Engelhardt (11):
build: use AM_CPPFLAGS
build: use only AC_CANONICAL_HOST
examples/genl: fix newline imbalance
examples/genl: support dumping the genl families
src: use limits.h header
include: use sanitized header from headers_install
build: abort autogen on subcommand failure
Update .gitignore
build: use AC_CONFIG_AUX_DIR and stash away tools
m4: resolve autoconf-2.68 warnings
build: disable implicit .tar.gz archive generation and use POSIX mode
Pablo Neira Ayuso (8):
header: fix invalid use of type void * in arithmetic of mnl_for_each_nest(...)
Merge branch 'master' of git://dev.medozas.de/libmnl
doc: don't show up EXPORT_SYMBOL in doxygen
doxygen: exclude EXPORT_SYMBOL and skip .git files
COPYING: update file (FSF address was outdated)
build: kernel-like compilation messages
example: release them in the public domain
build: libmnl 1.0.2 release
Sean Robinson (1):
doc: fix wrong comment describing mnl_nlmsg_batch_stop()
^ permalink raw reply
* Re: [BUG] SIOCSIFFLAGS returns -EIO on SMSC LAN911x
From: Javier Martinez Canillas @ 2012-01-02 18:37 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Enric Balletbo i Serra
In-Reply-To: <1325250948.13595.100.camel@deadeye>
On Fri, Dec 30, 2011 at 2:15 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Fri, 2011-12-30 at 13:58 +0100, Javier Martinez Canillas wrote:
>> On Fri, Dec 30, 2011 at 11:56 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> > On Fri, 2011-12-30 at 10:44 +0100, Javier Martinez Canillas wrote:
> [...]
>> >> Did anyone have the same problem?
>> >>
>> >> The problem is really strange to me, especially since we are sure that
>> >> all the requirements to software reset the device are meet in both
>> >> cases (with SMSC_PHY compiled built-in and without it)
>> >
>> > I don't know about that. smsc_phy_config_init() attempts to enable
>> > power-saving on the PHY, but it is writing to a bit that is reserved
>> > according to the data sheet for the combined MAC/PHY chip. dwein
>>
>> Since the PHY chip is a lan8700, the power-saving seems to be correct.
>
> But the feature may not be supported in the combined chip, the 9221i. I
> would tend to believe the more specific data sheet.
>
>> But the problem is when latter in the open handler a software reset is
>> attempt.
>>
>> Probably I can protect the software reset and only try to reset the
>> device if the PHY is now in a low power mode. But if we don't reset
>> the device at interface bringing up, when should we do a the reset?
>
> You may have to change the order of initialisation of the PHY and MAC so
> that reset works properly.
>
>> I'm not that familiarized with the networking layer, if someone can
>> give me some light I can fix the issue and send a patch.
>
> This really doesn't have much to do with general networking, only phylib
> and the specifics of the SMSC hardware and drivers. The smsc911x driver
> is responsible for calling phylib functions and so the hardware
> initialisation is very much under its control.
>
> Ben.
Hello Ben,
Thanks for your help.
Finally, what I did was to bring to operational mode the integrated
PHY chip by disabling the energy detect power-down mode before doing a
software reset and re-enabling after it.
Does that solution make sense to you? I've sent the patch-set to the
list for review. The patch-set is composed of the following patches:
Javier Martinez Canillas (2):
net: phy: smsc: Move SMSC PHY constants to <linux/smscphy.h>
net/smsc911x: Check if PHY is in operational mode before software reset
Thanks a lot and best regards,
--
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-02 18:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <CAL8zT=jKGYPe+bi44m0ADWzr+h0Hx59oGUYZoYsuu5syQQ-N5g@mail.gmail.com>
2012/1/2 Jean-Michel Hautbois <jhautbois@gmail.com>:
> 2012/1/2 Eric Dumazet <eric.dumazet@gmail.com>:
>> Le lundi 02 janvier 2012 à 18:20 +0100, Jean-Michel Hautbois a écrit :
>>
>>> Here we go...
>>>
>>> Recv Send Send
>>> Socket Socket Message Elapsed
>>> Size Size Size Time Throughput
>>> bytes bytes bytes secs. 10^6bits/sec
>>>
>>> 87380 16384 16384 60.01 21.79
>>>
>>> It is not very good, AFAIK.
>>> CPU usage is between 17 and 35%.
>>
>> Ouch...
>>
>> Better find out what is happening before even starting coding
>> anything...
>>
>> checkout "netstat -s" on both sender/receiver
>
> OK, here are the results :
> netserver is launched on the x86 side and the ARM and x86 are
> connected through ethernet network via a switch. There is nobody on
> this network.
>
> On ARM side :
> netperf -H 192.168.1.10 -l 60 -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.1.10 (192.168.1.10) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 60.02 22.01
> / # netstat -s
> Ip:
> 67326 total packets received
> 4 with invalid addresses
> 0 forwarded
> 0 incoming packets discarded
> 67322 incoming packets delivered
> 133712 requests sent out
> Icmp:
> 0 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> 0 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> Tcp:
> 4 active connections openings
> 0 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 0 connections established
> 67167 segments received
> 133712 segments send out
> 0 segments retransmited
> 0 bad segments received.
> 0 resets sent
> Udp:
> 0 packets received
> 0 packets to unknown port received.
> 0 packet receive errors
> 0 packets sent
> 0 receive buffer errors
> 0 send buffer errors
> UdpLite:
> TcpExt:
> 2 TCP sockets finished time wait in fast timer
> 2 delayed acks sent
> 18 packets directly queued to recvmsg prequeue.
> 3 packet headers predicted
> 127 acknowledgments not containing data payload received
> 67026 predicted acknowledgments
> IpExt:
> InBcastPkts: 155
> InOctets: 3511540
> OutOctets: 199739352
> InBcastOctets: 16072
>
> On the x86 side :
> netperf -H 192.168.1.10 -l 60 -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.1.10 (192.168.1.10) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 60.02 22.01
> / # netstat -s
> Ip:
> 67326 total packets received
> 4 with invalid addresses
> 0 forwarded
> 0 incoming packets discarded
> 67322 incoming packets delivered
> 133712 requests sent out
> Icmp:
> 0 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> 0 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> Tcp:
> 4 active connections openings
> 0 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 0 connections established
> 67167 segments received
> 133712 segments send out
> 0 segments retransmited
> 0 bad segments received.
> 0 resets sent
> Udp:
> 0 packets received
> 0 packets to unknown port received.
> 0 packet receive errors
> 0 packets sent
> 0 receive buffer errors
> 0 send buffer errors
> UdpLite:
> TcpExt:
> 2 TCP sockets finished time wait in fast timer
> 2 delayed acks sent
> 18 packets directly queued to recvmsg prequeue.
> 3 packet headers predicted
> 127 acknowledgments not containing data payload received
> 67026 predicted acknowledgments
> IpExt:
> InBcastPkts: 155
> InOctets: 3511540
> OutOctets: 199739352
> InBcastOctets: 16072
>
>
Sorry, bad copy/paste...
Here is the x86 side :
netstat -s
Ip:
134157 total packets received
14 with invalid addresses
0 forwarded
0 incoming packets discarded
134079 incoming packets delivered
67446 requests sent out
84 outgoing packets dropped
2 dropped because of missing route
Icmp:
86 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 86
92 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 92
IcmpMsg:
InType3: 86
OutType3: 92
Tcp:
0 active connections openings
4 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
133712 segments received
67167 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
294 packets received
92 packets to unknown port received.
0 packet receive errors
187 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
TcpExt:
1 delayed acks sent
133689 packets directly queued to recvmsg prequeue.
192786040 bytes directly received in process context from prequeue
0 packet headers predicted
133689 packets header predicted and directly queued to user
14 acknowledgments not containing data payload received
IpExt:
InBcastPkts: 140
OutBcastPkts: 51
InOctets: 199778186
OutOctets: 3519013
InBcastOctets: 14912
OutBcastOctets: 6639
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-02 18:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1325526085.18116.15.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
2012/1/2 Eric Dumazet <eric.dumazet@gmail.com>:
> Le lundi 02 janvier 2012 à 18:20 +0100, Jean-Michel Hautbois a écrit :
>
>> Here we go...
>>
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 87380 16384 16384 60.01 21.79
>>
>> It is not very good, AFAIK.
>> CPU usage is between 17 and 35%.
>
> Ouch...
>
> Better find out what is happening before even starting coding
> anything...
>
> checkout "netstat -s" on both sender/receiver
OK, here are the results :
netserver is launched on the x86 side and the ARM and x86 are
connected through ethernet network via a switch. There is nobody on
this network.
On ARM side :
netperf -H 192.168.1.10 -l 60 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.10 (192.168.1.10) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.02 22.01
/ # netstat -s
Ip:
67326 total packets received
4 with invalid addresses
0 forwarded
0 incoming packets discarded
67322 incoming packets delivered
133712 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
4 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
67167 segments received
133712 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
TcpExt:
2 TCP sockets finished time wait in fast timer
2 delayed acks sent
18 packets directly queued to recvmsg prequeue.
3 packet headers predicted
127 acknowledgments not containing data payload received
67026 predicted acknowledgments
IpExt:
InBcastPkts: 155
InOctets: 3511540
OutOctets: 199739352
InBcastOctets: 16072
On the x86 side :
netperf -H 192.168.1.10 -l 60 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.10 (192.168.1.10) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.02 22.01
/ # netstat -s
Ip:
67326 total packets received
4 with invalid addresses
0 forwarded
0 incoming packets discarded
67322 incoming packets delivered
133712 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
4 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
67167 segments received
133712 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
TcpExt:
2 TCP sockets finished time wait in fast timer
2 delayed acks sent
18 packets directly queued to recvmsg prequeue.
3 packet headers predicted
127 acknowledgments not containing data payload received
67026 predicted acknowledgments
IpExt:
InBcastPkts: 155
InOctets: 3511540
OutOctets: 199739352
InBcastOctets: 16072
JM
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Eric Dumazet @ 2012-01-02 17:41 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: netdev
In-Reply-To: <CAL8zT=gA2pd8wJtBRRLSH_MKXOj3_FzfcXg7v705+8w-xdByLg@mail.gmail.com>
Le lundi 02 janvier 2012 à 18:20 +0100, Jean-Michel Hautbois a écrit :
> Here we go...
>
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 60.01 21.79
>
> It is not very good, AFAIK.
> CPU usage is between 17 and 35%.
Ouch...
Better find out what is happening before even starting coding
anything...
checkout "netstat -s" on both sender/receiver
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-02 17:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1325523178.18116.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
2012/1/2 Eric Dumazet <eric.dumazet@gmail.com>:
> Le lundi 02 janvier 2012 à 17:52 +0100, Eric Dumazet a écrit :
>> Le lundi 02 janvier 2012 à 17:40 +0100, Jean-Michel Hautbois a écrit :
>>
>> > Mmmh, using netperf you would like to know what the client (my ARM
>> > board) can do ?
>> > How would you test it ? I can have an ARM board on one side, and the
>> > x86 on the other...
>> >
>>
>> x86> netserver &
>> arm> netperf -H <arm_ip_address> -l 60 -t TCP_STREAM
>>
>
> well it should be :
>
> arm> netperf -H <x86_ip_address> -l 60 -t TCP_STREAM
Here we go...
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.01 21.79
It is not very good, AFAIK.
CPU usage is between 17 and 35%.
^ permalink raw reply
* [PATCH 2/2] net/smsc911x: Check if PHY is in operational mode before software reset
From: Javier Martinez Canillas @ 2012-01-02 17:08 UTC (permalink / raw)
To: Steve Glendinning
Cc: Ben Hutchings, Enric Balletbo i Serra, netdev,
Javier Martinez Canillas
In-Reply-To: <1325524131-14585-1-git-send-email-martinez.javier@gmail.com>
SMSC LAN generation 4 chips integrate an IEEE 802.3 ethernet physical layer.
The PHY driver for this integrated chip enable an energy detect power-down mode.
When the PHY is in a power-down mode, it prevents the MAC portion chip to be
software reseted.
That means that if we compile the kernel with the configuration option SMSC_PHY
enabled and try to bring the network interface up without an cable plug-ed the
PHY will be in a low power mode and the software reset will fail returning -EIO
to user-space:
root@igep00x0:~# ifconfig eth0 up
ifconfig: SIOCSIFFLAGS: Input/output error
This patch disable the energy detect power-down mode before trying to software
reset the LAN chip and re-enables after it was reseted successfully.
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/net/ethernet/smsc/smsc911x.c | 88 ++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 8843071..2a63e11 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1243,10 +1243,88 @@ static void smsc911x_rx_multicast_update_workaround(struct smsc911x_data *pdata)
spin_unlock(&pdata->mac_lock);
}
+static int smsc911x_phy_disable_energy_detect(struct smsc911x_data *pdata)
+{
+ int rc = 0;
+
+ if (!pdata->phy_dev)
+ return rc;
+
+ rc = phy_read(pdata->phy_dev, MII_LAN83C185_CTRL_STATUS);
+
+ if (rc < 0) {
+ SMSC_WARN(pdata, drv, "Failed reading PHY control reg");
+ return rc;
+ }
+
+ /* If energy is detected the PHY is already awake so is not necessary
+ * to disable the energy detect power-down mode. */
+ if ((rc & MII_LAN83C185_EDPWRDOWN) &&
+ !(rc & MII_LAN83C185_ENERGYON)) {
+ /* Disable energy detect mode for this SMSC Transceivers */
+ rc = phy_write(pdata->phy_dev, MII_LAN83C185_CTRL_STATUS,
+ rc & (~MII_LAN83C185_EDPWRDOWN));
+
+ if (rc < 0) {
+ SMSC_WARN(pdata, drv, "Failed writing PHY control reg");
+ return rc;
+ }
+
+ mdelay(1);
+ }
+
+ return 0;
+}
+
+static int smsc911x_phy_enable_energy_detect(struct smsc911x_data *pdata)
+{
+ int rc = 0;
+
+ if (!pdata->phy_dev)
+ return rc;
+
+ rc = phy_read(pdata->phy_dev, MII_LAN83C185_CTRL_STATUS);
+
+ if (rc < 0) {
+ SMSC_WARN(pdata, drv, "Failed reading PHY control reg");
+ return rc;
+ }
+
+ /* Only enable if energy detect mode is already disabled */
+ if (!(rc & MII_LAN83C185_EDPWRDOWN)) {
+ mdelay(100);
+ /* Enable energy detect mode for this SMSC Transceivers */
+ rc = phy_write(pdata->phy_dev, MII_LAN83C185_CTRL_STATUS,
+ rc | MII_LAN83C185_EDPWRDOWN);
+
+ if (rc < 0) {
+ SMSC_WARN(pdata, drv, "Failed writing PHY control reg");
+ return rc;
+ }
+
+ mdelay(1);
+ }
+ return 0;
+}
+
static int smsc911x_soft_reset(struct smsc911x_data *pdata)
{
unsigned int timeout;
unsigned int temp;
+ int ret;
+
+ /* LAN9210/LAN9211/LAN9220/LAN9221 chips have an internal PHY that
+ * are initialized in a Energy Detect Power-Down mode that prevents
+ * the MAC chip to be software reseted. So we have to wakeup the PHY
+ * before */
+ if (pdata->generation == 4) {
+ ret = smsc911x_phy_disable_energy_detect(pdata);
+
+ if (ret) {
+ SMSC_WARN(pdata, drv, "Failed to wakeup the PHY chip");
+ return ret;
+ }
+ }
/* Reset the LAN911x */
smsc911x_reg_write(pdata, HW_CFG, HW_CFG_SRST_);
@@ -1260,6 +1338,16 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
SMSC_WARN(pdata, drv, "Failed to complete reset");
return -EIO;
}
+
+ if (pdata->generation == 4) {
+ ret = smsc911x_phy_enable_energy_detect(pdata);
+
+ if (ret) {
+ SMSC_WARN(pdata, drv, "Failed to wakeup the PHY chip");
+ return ret;
+ }
+ }
+
return 0;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] net: phy: smsc: Move SMSC PHY constants to <linux/smscphy.h>
From: Javier Martinez Canillas @ 2012-01-02 17:08 UTC (permalink / raw)
To: Steve Glendinning
Cc: Ben Hutchings, Enric Balletbo i Serra, netdev,
Javier Martinez Canillas
SMSC generation 4 LAN chips integrate an IEEE 802.3 ethernet physical layer.
The ethernet driver for this family of devices needs to access the SMSC PHY
registers and bits.
So, this patch moves these constants to a place where it can be used for both
the PHY and LAN drivers.
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/net/ethernet/smsc/smsc911x.h | 4 +++
drivers/net/phy/smsc.c | 21 +----------------
include/linux/smscphy.h | 42 ++++++++++++++++++++++++++++++++++
3 files changed, 47 insertions(+), 20 deletions(-)
create mode 100644 include/linux/smscphy.h
diff --git a/drivers/net/ethernet/smsc/smsc911x.h b/drivers/net/ethernet/smsc/smsc911x.h
index 8d67aac..938ecf2 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -401,4 +401,8 @@
#include <asm/smsc911x.h>
#endif
+#ifdef CONFIG_SMSC_PHY
+#include <linux/smscphy.h>
+#endif
+
#endif /* __SMSC911X_H__ */
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 342505c..fc3e7e9 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -22,26 +22,7 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/netdevice.h>
-
-#define MII_LAN83C185_ISF 29 /* Interrupt Source Flags */
-#define MII_LAN83C185_IM 30 /* Interrupt Mask */
-#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
-
-#define MII_LAN83C185_ISF_INT1 (1<<1) /* Auto-Negotiation Page Received */
-#define MII_LAN83C185_ISF_INT2 (1<<2) /* Parallel Detection Fault */
-#define MII_LAN83C185_ISF_INT3 (1<<3) /* Auto-Negotiation LP Ack */
-#define MII_LAN83C185_ISF_INT4 (1<<4) /* Link Down */
-#define MII_LAN83C185_ISF_INT5 (1<<5) /* Remote Fault Detected */
-#define MII_LAN83C185_ISF_INT6 (1<<6) /* Auto-Negotiation complete */
-#define MII_LAN83C185_ISF_INT7 (1<<7) /* ENERGYON */
-
-#define MII_LAN83C185_ISF_INT_ALL (0x0e)
-
-#define MII_LAN83C185_ISF_INT_PHYLIB_EVENTS \
- (MII_LAN83C185_ISF_INT6 | MII_LAN83C185_ISF_INT4 | \
- MII_LAN83C185_ISF_INT7)
-
-#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
+#include <linux/smscphy.h>
static int smsc_phy_config_intr(struct phy_device *phydev)
{
diff --git a/include/linux/smscphy.h b/include/linux/smscphy.h
new file mode 100644
index 0000000..c8eb7ed
--- /dev/null
+++ b/include/linux/smscphy.h
@@ -0,0 +1,42 @@
+/***************************************************************************
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ ***************************************************************************/
+#ifndef __LINUX_SMSCPHY_H__
+#define __LINUX_SMSCPHY_H__
+
+#define MII_LAN83C185_ISF 29 /* Interrupt Source Flags */
+#define MII_LAN83C185_IM 30 /* Interrupt Mask */
+#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
+
+#define MII_LAN83C185_ISF_INT1 (1<<1) /* Auto-Negotiation Page Received */
+#define MII_LAN83C185_ISF_INT2 (1<<2) /* Parallel Detection Fault */
+#define MII_LAN83C185_ISF_INT3 (1<<3) /* Auto-Negotiation LP Ack */
+#define MII_LAN83C185_ISF_INT4 (1<<4) /* Link Down */
+#define MII_LAN83C185_ISF_INT5 (1<<5) /* Remote Fault Detected */
+#define MII_LAN83C185_ISF_INT6 (1<<6) /* Auto-Negotiation complete */
+#define MII_LAN83C185_ISF_INT7 (1<<7) /* ENERGYON */
+
+#define MII_LAN83C185_ISF_INT_ALL (0x0e)
+
+#define MII_LAN83C185_ISF_INT_PHYLIB_EVENTS \
+ (MII_LAN83C185_ISF_INT6 | MII_LAN83C185_ISF_INT4 | \
+ MII_LAN83C185_ISF_INT7)
+
+#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
+#define MII_LAN83C185_ENERGYON (1 << 1) /* ENERGYON */
+
+#endif /* __LINUX_SMSCPHY_H__ */
--
1.7.4.1
^ permalink raw reply related
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-02 17:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1325523178.18116.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
2012/1/2 Eric Dumazet <eric.dumazet@gmail.com>:
> Le lundi 02 janvier 2012 à 17:52 +0100, Eric Dumazet a écrit :
>> Le lundi 02 janvier 2012 à 17:40 +0100, Jean-Michel Hautbois a écrit :
>>
>> > Mmmh, using netperf you would like to know what the client (my ARM
>> > board) can do ?
>> > How would you test it ? I can have an ARM board on one side, and the
>> > x86 on the other...
>> >
>>
>> x86> netserver &
>> arm> netperf -H <arm_ip_address> -l 60 -t TCP_STREAM
>>
>
> well it should be :
>
> arm> netperf -H <x86_ip_address> -l 60 -t TCP_STREAM
>
OK, I will now have to wait for the netperf servers to be up... :|.
JM
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Eric Dumazet @ 2012-01-02 16:52 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: netdev
In-Reply-To: <1325523137.18116.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le lundi 02 janvier 2012 à 17:52 +0100, Eric Dumazet a écrit :
> Le lundi 02 janvier 2012 à 17:40 +0100, Jean-Michel Hautbois a écrit :
>
> > Mmmh, using netperf you would like to know what the client (my ARM
> > board) can do ?
> > How would you test it ? I can have an ARM board on one side, and the
> > x86 on the other...
> >
>
> x86> netserver &
> arm> netperf -H <arm_ip_address> -l 60 -t TCP_STREAM
>
well it should be :
arm> netperf -H <x86_ip_address> -l 60 -t TCP_STREAM
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Eric Dumazet @ 2012-01-02 16:52 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: netdev
In-Reply-To: <CAL8zT=gbCmtNpw1Lot0P7zB+b_Kw911jhxsXCzO3JOBmMLRcFg@mail.gmail.com>
Le lundi 02 janvier 2012 à 17:40 +0100, Jean-Michel Hautbois a écrit :
> Mmmh, using netperf you would like to know what the client (my ARM
> board) can do ?
> How would you test it ? I can have an ARM board on one side, and the
> x86 on the other...
>
x86> netserver &
arm> netperf -H <arm_ip_address> -l 60 -t TCP_STREAM
1) check cpu usage on <arm> while test is running
(for example : vmstat 1 )
2) check bandwith of test run
> Yes, the idea of limiting tcp frame to 2 lines is to avoid
> fragmenting. So, with a MTU at 1500, MSS=1460, I can put 2 lines <=
> 730bytes. I will probably have ~700bytes.
There is no fragmentation on TCP.
You should just let TCP stack use the best MSS (MTU - 40 or so), to
lower cpu usage both on sender and receiver.
Eventually, check if you can use a big MTU on your dedicated ethernet
link to fit 4 lines per tcp frame.
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-02 16:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1325521745.18116.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>> I don't really know what it can do, but it has to do encoding (even if
>> it is a SoC, with dedicated devices, memory has to be used).
>> The main problem I have, is that I don't have the two boards with me
>> today, and even if I can prototype on x86, I can't conclude as far as
>> I don't test on the real HW.
>
> Thats going to be tough. You could at least use one board and test if it
> can send 100Mbits using netperf (on a x86 target), and check cpu usage.
Mmmh, using netperf you would like to know what the client (my ARM
board) can do ?
How would you test it ? I can have an ARM board on one side, and the
x86 on the other...
>> This is also why I want to prototype my best bet in the first try :).
>> And this is mainly a networking/memory problem.
>
> If the 'no packet loss happens in the network' requirement is OK, then a
> plain sendfile() [ or splice() ] will work.
>
> Limiting each tcp frame to a 1 or 2 lines of your image is about
> limiting MSS on your tcp session (setsockopt( ... TCP_MAXSEG ))
Yes, the idea of limiting tcp frame to 2 lines is to avoid
fragmenting. So, with a MTU at 1500, MSS=1460, I can put 2 lines <=
730bytes. I will probably have ~700bytes.
JM
^ 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