* [PATCH net-next-2.6 8/8] sfc: Bump version to 3.1
From: Ben Hutchings @ 2011-03-01 1:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1298942169.3069.179.camel@localhost>
All features originally planned for version 3.1 (and some that
weren't) have been implemented.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/net_driver.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index 9ea6cc2..215d5c5 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -41,7 +41,7 @@
*
**************************************************************************/
-#define EFX_DRIVER_VERSION "3.0"
+#define EFX_DRIVER_VERSION "3.1"
#ifdef EFX_ENABLE_DEBUG
#define EFX_BUG_ON_PARANOID(x) BUG_ON(x)
--
1.5.4
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
From: Andy Gospodarek @ 2011-03-01 2:35 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Andy Gospodarek, netdev, David Miller, Herbert Xu, Jay Vosburgh,
Jiri Pirko
In-Reply-To: <4D6C1764.1040008@gmail.com>
On Mon, Feb 28, 2011 at 10:45:08PM +0100, Nicolas de Pesloüan wrote:
> Le 28/02/2011 17:32, Andy Gospodarek a écrit :
>> On Sat, Feb 26, 2011 at 12:08:03AM +0100, Nicolas de Pesloüan wrote:
>>> Le 25/02/2011 23:24, Andy Gospodarek a écrit :
>> [...]
>>>>
>>>> I confirmed your suspicion, this breaks ARP monitoring. I would still
>>>> welcome other opinions though as I think it would be nice to fix this as
>>>> low as possible.
>>>
>>> Why do you want to fix it earlier that in ndisc_recv_ns drop? Your
>>> original idea of silently dropping the frame there seems perfect to me.
>>>
>>
>> Maybe it's just me, but I cannot understand why we want a bunch of extra
>> packets floating up into the stack when they may only create issues for
>> the recipients of these duplicate frames.
>>
>> Clearly my original patch needs to be refined so ARP monitoring still
>> works, but I would rather fix the issue there than in a higher layer.
>
> Jay explained that the current implementation should already trap those
> frames, on inactive slaves, in modes where inactive slaves exist. I agree
> with him.
>
> What mode are you seeing this problem in? If the current "should drop"
> logic is leaking, then yes, we should fix it. But we currently don't see
> where it is leaking.
>
Use round-robin. To reproduce just take the interface down and bring it
back up. You should see the messages right away.
I've been doing some more testing on a new patch and should have
something ready tomorrow. My latest patch actually replaces the final
'return 0' with a call to a function that will return true if the sender
was the device that received it. This will hopefully prevent some of
the failures with the first patch I posted. I'll know a bit more
tomorrow if this approach seems reasonable.
^ permalink raw reply
* [PATCH] cxgb{3,4}*: improve Kconfig dependencies
From: Dimitris Michailidis @ 2011-03-01 3:34 UTC (permalink / raw)
To: netdev; +Cc: linux-scsi, JBeulich, Dimitris Michailidis
- Remove the dependency of cxgb4 and cxgb4vf on INET. cxgb3 really
depends on INET, keep it but add it directly to the driver's Kconfig
entry.
- Make the iSCSI drivers cxgb3i and cxgb4i available in the SCSI menu
without requiring any options in the net driver menu to be enabled
first. Add needed selects so the iSCSI drivers can build their
corresponding net drivers.
- Remove CHELSIO_T*_DEPENDS.
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/Kconfig | 21 +++------------------
drivers/scsi/cxgbi/cxgb3i/Kconfig | 4 +++-
drivers/scsi/cxgbi/cxgb4i/Kconfig | 4 +++-
3 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f4b3927..6e09d5f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2595,14 +2595,9 @@ config CHELSIO_T1_1G
Enables support for Chelsio's gigabit Ethernet PCI cards. If you
are using only 10G cards say 'N' here.
-config CHELSIO_T3_DEPENDS
- tristate
- depends on PCI && INET
- default y
-
config CHELSIO_T3
tristate "Chelsio Communications T3 10Gb Ethernet support"
- depends on CHELSIO_T3_DEPENDS
+ depends on PCI && INET
select FW_LOADER
select MDIO
help
@@ -2620,14 +2615,9 @@ config CHELSIO_T3
To compile this driver as a module, choose M here: the module
will be called cxgb3.
-config CHELSIO_T4_DEPENDS
- tristate
- depends on PCI && INET
- default y
-
config CHELSIO_T4
tristate "Chelsio Communications T4 Ethernet support"
- depends on CHELSIO_T4_DEPENDS
+ depends on PCI
select FW_LOADER
select MDIO
help
@@ -2645,14 +2635,9 @@ config CHELSIO_T4
To compile this driver as a module choose M here; the module
will be called cxgb4.
-config CHELSIO_T4VF_DEPENDS
- tristate
- depends on PCI && INET
- default y
-
config CHELSIO_T4VF
tristate "Chelsio Communications T4 Virtual Function Ethernet support"
- depends on CHELSIO_T4VF_DEPENDS
+ depends on PCI
help
This driver supports Chelsio T4-based gigabit and 10Gb Ethernet
adapters with PCI-E SR-IOV Virtual Functions.
diff --git a/drivers/scsi/cxgbi/cxgb3i/Kconfig b/drivers/scsi/cxgbi/cxgb3i/Kconfig
index 5cf4e98..11dff23 100644
--- a/drivers/scsi/cxgbi/cxgb3i/Kconfig
+++ b/drivers/scsi/cxgbi/cxgb3i/Kconfig
@@ -1,6 +1,8 @@
config SCSI_CXGB3_ISCSI
tristate "Chelsio T3 iSCSI support"
- depends on CHELSIO_T3_DEPENDS
+ depends on PCI && INET
+ select NETDEVICES
+ select NETDEV_10000
select CHELSIO_T3
select SCSI_ISCSI_ATTRS
---help---
diff --git a/drivers/scsi/cxgbi/cxgb4i/Kconfig b/drivers/scsi/cxgbi/cxgb4i/Kconfig
index bb94b39..d5302c2 100644
--- a/drivers/scsi/cxgbi/cxgb4i/Kconfig
+++ b/drivers/scsi/cxgbi/cxgb4i/Kconfig
@@ -1,6 +1,8 @@
config SCSI_CXGB4_ISCSI
tristate "Chelsio T4 iSCSI support"
- depends on CHELSIO_T4_DEPENDS
+ depends on PCI && INET
+ select NETDEVICES
+ select NETDEV_10000
select CHELSIO_T4
select SCSI_ISCSI_ATTRS
---help---
--
1.7.3.4
^ permalink raw reply related
* Re: txqueuelen has wrong units; should be time
From: Albert Cahalan @ 2011-03-01 4:11 UTC (permalink / raw)
To: John Heffner
Cc: John W. Linville, Eric Dumazet, Jussi Kivilinna,
Mikael Abrahamsson, linux-kernel, netdev
In-Reply-To: <AANLkTinj5szpStmA+fZ1xggdyTS+sd8Y9jXaYquDNEjs@mail.gmail.com>
On Mon, Feb 28, 2011 at 4:45 PM, John Heffner <johnwheffner@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 11:55 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Mon, Feb 28, 2011 at 05:48:14PM +0100, Eric Dumazet wrote:
>>> Le lundi 28 février 2011 à 11:11 -0500, John W. Linville a écrit :
>>> > On Sun, Feb 27, 2011 at 09:07:53PM +0100, Eric Dumazet wrote:
>>> > > Qdisc should return to caller a good indication packet is queued or
>>> > > dropped at enqueue() time... not later (aka : never)
>>> > >
>>> > > Accepting a packet at t0, and dropping it later at t0+limit without
>>> > > giving any indication to caller is a problem.
>>> >
>>> > Can you elaborate on what problem this causes? Is it any worse than
>>> > if the packet is dropped at some later hop?
>>> >
>>> > Is there any API that could report the drop to the sender (at
>>> > least a local one) without having to wait for the ack timeout?
>>> > Should there be?
>>>
>>> Not all protocols have ACKS ;)
>>>
>>> dev_queue_xmit() returns an error code, some callers use it.
>>
>> Well, OK -- I agree it is best if you can return the status at
>> enqueue time. The question becomes whether or not a dropped frame
>> is worse than living with high latency. The answer, of course, still
>> seems to be a bit subjective. But, if the admin has determined that
>> a link should be low latency...?
>
> Notably, TCP is one caller that uses the error code. The error code
> is functionally equivalent to ECN, one of whose great advantages is
> reducing delay jitter. If TCP didn't get the error, that would
> effectively double the latency for a full window of data, since the
> dropped segment would not be retransmitted for an RTT.
It sounds like you need a callback or similar, so that TCP can be
informed later that the drop has occurred.
^ permalink raw reply
* Urgent Payment Information From Western Union!!
From: WESTERN UNION MONEY TRANSFER @ 2011-03-01 4:02 UTC (permalink / raw)
Good day,
I write to inform you that we have already sent you $5000.00 USD dollars
through Western Union as we have been given the mandate to transfer your
full compensation payment of $2.5Million Dollars via Western Union by the United
Nations Government.So I decided to email you the MTCN and sender's name
so you can pick up this $5000.00 USD to enable us send another $5000.00
USD by tomorrow as you know we will be sending you only $5000.00 USD per
day. Please pick up this information and run to any Western Union in your
country to pick up the $5000.00 USD and call me back to send you another
payment tomorrow. However we have noted you as a customer of western union
money transfer.
Manager: Mr Frank Amos.
Email: wumt66657@yahoo.com.hk
Tel number:+2347067137893
Call or email me once you picked up this $5,000 USD today. Here is the
western union information below.
Sender`s First Name:_______Idrus
Sender's Last Name:________Jemain
MTCN:______________________115-065-5463
Amount;=___________________$5,000, USD
Test Question;= ___________Honest?
Test Answer;= _____________Trust
Mean while i want you to give me a call if there is any problem
my telephone number is +2347067137893
Regards,
Tel number:+2347067137893
Mr Frank Amos.
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: David Miller @ 2011-03-01 4:18 UTC (permalink / raw)
To: acahalan
Cc: johnwheffner, linville, eric.dumazet, jussi.kivilinna, swmike,
linux-kernel, netdev
In-Reply-To: <AANLkTinFZu5AgfhO6PoA7C1NTGSfD8HH0KXq_o-mHEJF@mail.gmail.com>
From: Albert Cahalan <acahalan@gmail.com>
Date: Mon, 28 Feb 2011 23:11:13 -0500
> It sounds like you need a callback or similar, so that TCP can be
> informed later that the drop has occurred.
By that point we could have already sent an entire RTT's worth
of data, or more.
It needs to be synchronous, otherwise performance suffers.
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Eric Dumazet @ 2011-03-01 5:01 UTC (permalink / raw)
To: Albert Cahalan
Cc: John Heffner, John W. Linville, Jussi Kivilinna,
Mikael Abrahamsson, linux-kernel, netdev
In-Reply-To: <AANLkTinFZu5AgfhO6PoA7C1NTGSfD8HH0KXq_o-mHEJF@mail.gmail.com>
Le lundi 28 février 2011 à 23:11 -0500, Albert Cahalan a écrit :
> It sounds like you need a callback or similar, so that TCP can be
> informed later that the drop has occurred.
There is the thing called skb destructor / skb_orphan() mess, that is
not stackable... Might extend this to something more clever, and be able
to call functions (into TCP stack for example) giving a status of skb :
Sent, or dropped somewhere in the stack...
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-03-01 5:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298634040.2659.32.camel@edumazet-laptop>
Hi Eric,
On Fri, Feb 25, 2011 at 7:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 25 février 2011 à 17:57 +0800, Po-Yu Chuang a écrit :
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>>
>> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
>> MII. This driver has been working on some ARM/NDS32 SoC's including
>> Faraday A320 and Andes AG101.
>>
>> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> It seems fine to me, but I have somes questions
>
> 1) On V5, the receive function ftmac100_rx_packet() was able to process
> several segments per skb. On V6 you process one frag only.
>
> Isnt this NIC able to handle large MTU (say... 9000) ?
No, it isn't. Its max supported packet size is 0x7ff (2047 bytes).
I wasn't sure when will get multi-segment packet. After confirmed with
HW designer two weeks ago, he told me that only if the rx buffer described
by the first descriptor is not big enough, another rx buffer will be used.
That means, since every rx buffer is large enough, it is impossible to
get a multi-segment packets.
So I simplified ftmac100_rx_packet().
>
> 2) ftmac100_alloc_rx_page() is called and allocate a full page for a
> rxdes.
>
> 128*4K -> 512 Kbytes of memory for RX ring
>
> In V5, you were using half pages only, so 256 kbytes of memory.
>
> If you look at other drivers (NIU, BENET), they are able to use exactly
> 128*2 kbytes (for a rxring of 128 slots, and 2Kbytes per slot)
Both NIU and BENET refill rx ring after all packets receive work done,
but I allocate rx buffer right after a packet is received. I think it
is difficult
to use a page for two rx buffers in my driver now. Can we just keep it
the way it is? I can study how to achieve that after current driver is accepted.
best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-03-01 5:26 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <AANLkTimeDR27Q7fcBmB0ix7Q_pRT_GDpc7S3LO21-fh-@mail.gmail.com>
Le mardi 01 mars 2011 à 13:20 +0800, Po-Yu Chuang a écrit :
> Hi Eric,
>
> On Fri, Feb 25, 2011 at 7:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Both NIU and BENET refill rx ring after all packets receive work done,
> but I allocate rx buffer right after a packet is received. I think it
> is difficult
> to use a page for two rx buffers in my driver now. Can we just keep it
> the way it is? I can study how to achieve that after current driver is accepted.
>
No problem, you are the author, I am only a reviewer and ask questions
after all ;)
Thanks !
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-01 5:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Le lundi 28 février 2011 à 17:17 -0800, Stephen Hemminger a écrit :
> This is an implementation of the Quick Fair Queue scheduler developed
> by Fabio Checconi. The same algorithm is already implemented in ipfw
> in FreeBSD. Fabio had an earlier version developed on Linux, I just
> cleaned it up and tested it. All bugs are mine.
>
> This version is still experimental, do not use for production.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Seems very complex stuff ;)
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll perform some tests today with QFQ, thanks !
^ permalink raw reply
* Re: [PATCH 4/5] udp: Add lockless transmit path
From: Eric Dumazet @ 2011-03-01 5:30 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev, Thomas Graf
In-Reply-To: <E1Pu1TJ-0005RA-DV@gondolin.me.apana.org.au>
Le lundi 28 février 2011 à 19:41 +0800, Herbert Xu a écrit :
> udp: Add lockless transmit path
>
> The UDP transmit path has been running under the socket lock
> for a long time because of the corking feature. This means that
> transmitting to the same socket in multiple threads does not
> scale at all.
>
> However, as most users don't actually use corking, the locking
> can be removed in the common case.
>
> This patch creates a lockless fast path where corking is not used.
>
> Please note that this does create a slight inaccuracy in the
> enforcement of socket send buffer limits. In particular, we
> may exceed the socket limit by up to (number of CPUs) * (packet
> size) because of the way the limit is computed.
>
> As the primary purpose of socket buffers is to indicate congestion,
> this should not be a great problem for now.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
So far I found no obvious problem, and got pretty impressive results.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/5] net: Remove unused sk_sndmsg_* from UFO
From: Eric Dumazet @ 2011-03-01 5:31 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev, Thomas Graf
In-Reply-To: <E1Pu1TI-0005Qa-KA@gondolin.me.apana.org.au>
Le lundi 28 février 2011 à 19:41 +0800, Herbert Xu a écrit :
> net: Remove unused sk_sndmsg_* from UFO
>
> UFO doesn't really use the sk_sndmsg_* parameters so touching
> them is pointless. It can't use them anyway since the whole
> point of UFO is to use the original pages without copying.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/5] net: Remove explicit write references to sk/inet in ip_append_data
From: Eric Dumazet @ 2011-03-01 5:31 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev, Thomas Graf
In-Reply-To: <E1Pu1TI-0005Qj-T7@gondolin.me.apana.org.au>
Le lundi 28 février 2011 à 19:41 +0800, Herbert Xu a écrit :
> net: Remove explicit write references to sk/inet in ip_append_data
>
> In order to allow simultaneous calls to ip_append_data on the same
> socket, it must not modify any shared state in sk or inet (other
> than those that are designed to allow that such as atomic counters).
>
> This patch abstracts out write references to sk and inet_sk in
> ip_append_data and its friends so that we may use the underlying
> code in parallel.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
>
> include/net/inet_sock.h | 23 ++--
> net/ipv4/ip_output.c | 238 ++++++++++++++++++++++++++++--------------------
> 2 files changed, 154 insertions(+), 107 deletions(-)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/5] inet: Add ip_make_skb and ip_send_skb
From: Eric Dumazet @ 2011-03-01 5:31 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev, Thomas Graf
In-Reply-To: <E1Pu1TJ-0005Qw-5I@gondolin.me.apana.org.au>
Le lundi 28 février 2011 à 19:41 +0800, Herbert Xu a écrit :
> inet: Add ip_make_skb and ip_send_skb
>
> This patch adds the helper ip_make_skb which is like ip_append_data
> and ip_push_pending_frames all rolled into one, except that it does
> not send the skb produced. The sending part is carried out by
> ip_send_skb, which the transport protocol can call after it has
> tweaked the skb.
>
> It is meant to be called in cases where corking is not used should
> have a one-to-one correspondence to sendmsg.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-01 5:33 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, rick.jones2, therbert, wsommerfeld, daniel.baluta,
netdev
In-Reply-To: <20110228113659.GA20726@gondor.apana.org.au>
Le lundi 28 février 2011 à 19:36 +0800, Herbert Xu a écrit :
> Here are the patches I used. Please don't them yet as I intend
> to clean them up quite a bit.
>
I assume you mean "please dont commit them" ;)
> But please do test them heavily, especially if you have an AMD
> NUMA machine as that's where scalability problems really show
> up. Intel tends to be a lot more forgiving. My last AMD machine
> blew up years ago :)
Same here, My only AMD machine is a desktop class machine, not a server.
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Eric Dumazet @ 2011-03-01 5:36 UTC (permalink / raw)
To: Albert Cahalan
Cc: John Heffner, John W. Linville, Jussi Kivilinna,
Mikael Abrahamsson, linux-kernel, netdev
In-Reply-To: <1298955683.2676.2.camel@edumazet-laptop>
Le mardi 01 mars 2011 à 06:01 +0100, Eric Dumazet a écrit :
> Le lundi 28 février 2011 à 23:11 -0500, Albert Cahalan a écrit :
>
> > It sounds like you need a callback or similar, so that TCP can be
> > informed later that the drop has occurred.
>
> There is the thing called skb destructor / skb_orphan() mess, that is
> not stackable... Might extend this to something more clever, and be able
> to call functions (into TCP stack for example) giving a status of skb :
> Sent, or dropped somewhere in the stack...
>
One problem of such schem is the huge extra cost involved, extra
locking, extra memory allocations, extra atomic operations...
^ permalink raw reply
* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-03-01 5:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, linux-kernel, bhutchings, joe, dilinger,
mirqus, ratbert, Ajit Khaparde
In-Reply-To: <1298659663.2659.104.camel@edumazet-laptop>
Hi Eric,
On Sat, Feb 26, 2011 at 2:47 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 25 février 2011 à 19:45 +0100, Eric Dumazet a écrit :
>> Le vendredi 25 février 2011 à 10:34 -0800, David Miller a écrit :
>> > From: Eric Dumazet <eric.dumazet@gmail.com>
>> > Date: Fri, 25 Feb 2011 11:52:07 +0100
>> >
>> > > Le vendredi 25 février 2011 à 17:45 +0800, Po-Yu Chuang a écrit :
>> > >
>> > >> It's a little faster than v5 now. Thanks.
>> > >> I will submit the current version later.
>> > >>
>> > >> One more question just curious, why 128 bytes?
>> > >
>> > > Probably its best for NIU hardware specs
>> > >
>> > > You could try 64, as it should be enough for most IP/TCP/UDP processing.
>> >
>> > IPV6.
>>
>> drivers/net/benet/be.h:70:#define BE_HDR_LEN 64
>>
>> Maybe we should have a comment somewhere.
>>
>> CC Ajit Khaparde <ajit.khaparde@emulex.com>
>>
>
>
> A compromise would be to use 128 for the allocation, but only copy 64
> bytes.
I will use this way and submit v7 later.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-03-01 5:45 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <AANLkTimeDR27Q7fcBmB0ix7Q_pRT_GDpc7S3LO21-fh-@mail.gmail.com>
Le mardi 01 mars 2011 à 13:20 +0800, Po-Yu Chuang a écrit :
> That means, since every rx buffer is large enough, it is impossible to
> get a multi-segment packets.
>
> So I simplified ftmac100_rx_packet().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I am only wondering then if not using fragments would be faster then
(eventually doing copybreaks for small frames like tg3)
But if you plan to get new hw soon, you have the infrastructure...
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
From: Jay Vosburgh @ 2011-03-01 5:46 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Nicolas de =?iso-8859-1?Q?Peslo=FCan?=, netdev, David Miller,
Herbert Xu, Jiri Pirko
In-Reply-To: <20110301023525.GK11864@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>On Mon, Feb 28, 2011 at 10:45:08PM +0100, Nicolas de Pesloüan wrote:
>> Le 28/02/2011 17:32, Andy Gospodarek a écrit :
>>> On Sat, Feb 26, 2011 at 12:08:03AM +0100, Nicolas de Pesloüan wrote:
>>>> Le 25/02/2011 23:24, Andy Gospodarek a écrit :
>>> [...]
>>>>>
>>>>> I confirmed your suspicion, this breaks ARP monitoring. I would still
>>>>> welcome other opinions though as I think it would be nice to fix this as
>>>>> low as possible.
>>>>
>>>> Why do you want to fix it earlier that in ndisc_recv_ns drop? Your
>>>> original idea of silently dropping the frame there seems perfect to me.
>>>>
>>>
>>> Maybe it's just me, but I cannot understand why we want a bunch of extra
>>> packets floating up into the stack when they may only create issues for
>>> the recipients of these duplicate frames.
>>>
>>> Clearly my original patch needs to be refined so ARP monitoring still
>>> works, but I would rather fix the issue there than in a higher layer.
>>
>> Jay explained that the current implementation should already trap those
>> frames, on inactive slaves, in modes where inactive slaves exist. I agree
>> with him.
>>
>> What mode are you seeing this problem in? If the current "should drop"
>> logic is leaking, then yes, we should fix it. But we currently don't see
>> where it is leaking.
>>
>
>Use round-robin. To reproduce just take the interface down and bring it
>back up. You should see the messages right away.
What is the bond connected to? The -rr and -xor modes are meant
to interoperate with switch ports configured for Etherchannel (or an
equivalent). In that case, I wouldn't expect the switch to turn the
broadcasts / multicasts around and send them back out to a member of the
channel group they originated from.
If the switch isn't configured properly, then I'd expect it to
complain about MAC flapping or the like. Unless it's an unmanaged
switch that doesn't do Etherchannel (etc), or you're setting up an
unusual topology.
>I've been doing some more testing on a new patch and should have
>something ready tomorrow. My latest patch actually replaces the final
>'return 0' with a call to a function that will return true if the sender
>was the device that received it. This will hopefully prevent some of
>the failures with the first patch I posted. I'll know a bit more
>tomorrow if this approach seems reasonable.
How do you figure that out? In -rr mode, all of the slaves
should have the same MAC address, and the slaves shouldn't be running
IPv6 addrconf separately from the master anyway. Something magic just
for NA/NS packets?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-03-01 5:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298958336.2676.21.camel@edumazet-laptop>
Hi Eric,
On Tue, Mar 1, 2011 at 1:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 01 mars 2011 à 13:20 +0800, Po-Yu Chuang a écrit :
>
>> That means, since every rx buffer is large enough, it is impossible to
>> get a multi-segment packets.
>>
>> So I simplified ftmac100_rx_packet().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Ah, I just want to submit a v7.
Could you resign again later, please? :-)
> I am only wondering then if not using fragments would be faster then
> (eventually doing copybreaks for small frames like tg3)
Although not many circumstances are tested.
iperf shows that it is a little faster to use fragments than memcpy, so...
> But if you plan to get new hw soon, you have the infrastructure...
best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-03-01 5:53 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: David Miller, netdev, linux-kernel, bhutchings, joe, dilinger,
mirqus, ratbert, Ajit Khaparde
In-Reply-To: <AANLkTi=MQoEKY5OLLN6f8-N7eD--Q6hL99HFFTAGU_Y4@mail.gmail.com>
Le mardi 01 mars 2011 à 13:45 +0800, Po-Yu Chuang a écrit :
> Hi Eric,
>
> On Sat, Feb 26, 2011 at 2:47 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > A compromise would be to use 128 for the allocation, but only copy 64
> > bytes.
>
> I will use this way and submit v7 later.
>
BTW, even with IPV6, the first 64 bytes contain "RPS" header
We changed NET_SKB_PAD a while back and added this comment in
include/linux/skbuff.h
NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + ports(8)
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-03-01 5:54 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <AANLkTi=Sp-mAV1556pZvCvHzQ=MQNHUzjo0ap2DhKwWe@mail.gmail.com>
Le mardi 01 mars 2011 à 13:51 +0800, Po-Yu Chuang a écrit :
> Ah, I just want to submit a v7.
> Could you resign again later, please? :-)
Sure
^ permalink raw reply
* Re: [PATCH v6] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-03-01 5:59 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <AANLkTi=Sp-mAV1556pZvCvHzQ=MQNHUzjo0ap2DhKwWe@mail.gmail.com>
Le mardi 01 mars 2011 à 13:51 +0800, Po-Yu Chuang a écrit :
> On Tue, Mar 1, 2011 at 1:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > I am only wondering then if not using fragments would be faster then
> > (eventually doing copybreaks for small frames like tg3)
>
> Although not many circumstances are tested.
> iperf shows that it is a little faster to use fragments than memcpy, so...
This might be a side effect of skb->truesize being smaller with
fragments than "regular packets" and socket backlog congestion.
If a full page was really accounted for in skb->truesize, instead of
used length, performance might be the same or lower :(
- skb->truesize += length;
+ skb->truesize += PAGE_SIZE;
This has nothing to do with your driver, but a core implementation
detail.
^ permalink raw reply
* Re: dccp: null-pointer dereference on close
From: Gerrit Renker @ 2011-03-01 5:59 UTC (permalink / raw)
To: Johan Hovold; +Cc: dccp, netdev
In-Reply-To: <20110226174505.GB3609@localhost>
[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]
Johan,
thanks a lot for the detailed description.
I think I have found the cause of the dccp timewait problem: in the
mainline tree there is a path
dccp_v4_do_rcv()
|
| state other than OPEN
v
dccp_rcv_state_process()
|
| DCCP_PKT_RESET
v
dccp_rcv_reset()
|
v
dccp_time_wait()
In the backtrace dccp_close() had been called, hence dccp_set_state() has
destroyed inet_csk(sk)->icsk_bind_hash, which then subsequently in the
misplaced dccp_time_wait() caused the NULL pointer exception.
I have just checked, this problem seems to not be possible in the test
tree, since it checks first in dccp_rcv_state_process() if DCCP_CLOSED
has been entered (if it receives a packet in this state, it sends a
Reset with code 3, "No Connection").
I am attaching the relevant patch from the test tree - would it be possible
for you to test it with the same setup? (The relevant passage is right in
the first hunk, where it tests for state == DCCP_CLOSED).
Will submit this patch subsequently also.
Thanks again,
Gerrit
| root@overo:~# [84140.128631] ------------[ cut here ]------------
| [84140.133575] WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
| [84140.142517] Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
| [84140.151794] [<c0038850>] (unwind_backtrace+0x0/0xec) from [<c0055364>] (warn_slowpath_common)
| [84140.161743] [<c0055364>] (warn_slowpath_common+0x4c/0x64) from [<c0055398>] (warn_slowpath_n)
| [84140.171966] [<c0055398>] (warn_slowpath_null+0x1c/0x24) from [<c02b72d0>] (__inet_twsk_hashd)
| [84140.182373] [<c02b72d0>] (__inet_twsk_hashdance+0x48/0x128) from [<c031caa0>] (dccp_time_wai)
| [84140.192413] [<c031caa0>] (dccp_time_wait+0x40/0xc8) from [<c031c15c>] (dccp_rcv_state_proces)
| [84140.202636] [<c031c15c>] (dccp_rcv_state_process+0x120/0x538) from [<c032609c>] (dccp_v4_do_)
| [84140.213043] [<c032609c>] (dccp_v4_do_rcv+0x11c/0x14c) from [<c0286594>] (release_sock+0xac/0)
| [84140.222442] [<c0286594>] (release_sock+0xac/0x110) from [<c031fd34>] (dccp_close+0x28c/0x380)
| [84140.231475] [<c031fd34>] (dccp_close+0x28c/0x380) from [<c02d9a78>] (inet_release+0x64/0x70)
| [84140.240386] [<c02d9a78>] (inet_release+0x64/0x70) from [<c0284ddc>] (sock_release+0x24/0xb8)
| [84140.249328] [<c0284ddc>] (sock_release+0x24/0xb8) from [<c0284e94>] (sock_close+0x24/0x34)
| [84140.258087] [<c0284e94>] (sock_close+0x24/0x34) from [<c00c2e4c>] (fput+0x108/0x1f4)
| [84140.266296] [<c00c2e4c>] (fput+0x108/0x1f4) from [<c00c0104>] (filp_close+0x70/0x7c)
| [84140.274505] [<c00c0104>] (filp_close+0x70/0x7c) from [<c00c01c4>] (sys_close+0xb4/0x10c)
| [84140.283081] [<c00c01c4>] (sys_close+0xb4/0x10c) from [<c0033a80>] (ret_fast_syscall+0x0/0x30)
| [84140.292114] ---[ end trace b8877ec9d542c32e ]---
| [84140.296997] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[-- Attachment #2: DCCP_Reorder-Input-Processing.diff --]
[-- Type: text/x-diff, Size: 5694 bytes --]
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which can consume resources) now comes after step 7.
2. Bug-fix: in state CLOSED, there should not be any sequence number checking
or option processing. This is why the test for CLOSED has been moved after
the test for LISTEN.
3. As before sequence number checks are omitted if in state LISTEN/REQUEST, due
to the note underneath the table in RFC 4340, 7.5.3.
4. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
As a result of (3), CCID processing is now indeed confined to OPEN/PARTOPEN
states, i.e. congestion control is performed only on the flow of data packets.
This avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
I have done some checks to see if this creates a problem in other parts of
the code. This seems not to be the case; even if there were one, it would be
better to fix it than to perform congestion control on Close/Request/Response
messages. Similarly for Ack Vectors (as they depend on the negotiated CCID).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 68 ++++++++++++++++++++++++++-----------------------------
1 file changed, 33 insertions(+), 35 deletions(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -614,22 +614,36 @@ int dccp_rcv_state_process(struct sock *
/* Caller (dccp_v4_do_rcv) will send Reset */
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
return 1;
+ } else if (sk->sk_state == DCCP_CLOSED) {
+ dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
+ return 1;
}
- if (sk->sk_state != DCCP_REQUESTING && sk->sk_state != DCCP_RESPOND) {
- if (dccp_check_seqno(sk, skb))
- goto discard;
-
- /*
- * Step 8: Process options and mark acknowledgeable
- */
- if (dccp_parse_options(sk, NULL, skb))
- return 1;
+ /* Step 6: Check sequence numbers (omitted in LISTEN/REQUEST state) */
+ if (sk->sk_state != DCCP_REQUESTING && dccp_check_seqno(sk, skb))
+ goto discard;
- dccp_handle_ackvec_processing(sk, skb);
- dccp_deliver_input_to_ccids(sk, skb);
+ /*
+ * Step 7: Check for unexpected packet types
+ * If (S.is_server and P.type == Response)
+ * or (S.is_client and P.type == Request)
+ * or (S.state == RESPOND and P.type == Data),
+ * Send Sync packet acknowledging P.seqno
+ * Drop packet and return
+ */
+ if ((dp->dccps_role != DCCP_ROLE_CLIENT &&
+ dh->dccph_type == DCCP_PKT_RESPONSE) ||
+ (dp->dccps_role == DCCP_ROLE_CLIENT &&
+ dh->dccph_type == DCCP_PKT_REQUEST) ||
+ (sk->sk_state == DCCP_RESPOND && dh->dccph_type == DCCP_PKT_DATA)) {
+ dccp_send_sync(sk, dcb->dccpd_seq, DCCP_PKT_SYNC);
+ goto discard;
}
+ /* Step 8: Process options */
+ if (dccp_parse_options(sk, NULL, skb))
+ return 1;
+
/*
* Step 9: Process Reset
* If P.type == Reset,
@@ -637,41 +651,21 @@ int dccp_rcv_state_process(struct sock *
* S.state := TIMEWAIT
* Set TIMEWAIT timer
* Drop packet and return
- */
+ */
if (dh->dccph_type == DCCP_PKT_RESET) {
dccp_rcv_reset(sk, skb);
return 0;
- /*
- * Step 7: Check for unexpected packet types
- * If (S.is_server and P.type == Response)
- * or (S.is_client and P.type == Request)
- * or (S.state == RESPOND and P.type == Data),
- * Send Sync packet acknowledging P.seqno
- * Drop packet and return
- */
- } else if ((dp->dccps_role != DCCP_ROLE_CLIENT &&
- dh->dccph_type == DCCP_PKT_RESPONSE) ||
- (dp->dccps_role == DCCP_ROLE_CLIENT &&
- dh->dccph_type == DCCP_PKT_REQUEST) ||
- (sk->sk_state == DCCP_RESPOND &&
- dh->dccph_type == DCCP_PKT_DATA)) {
- dccp_send_sync(sk, dcb->dccpd_seq, DCCP_PKT_SYNC);
- goto discard;
- } else if (dh->dccph_type == DCCP_PKT_CLOSEREQ) {
+ } else if (dh->dccph_type == DCCP_PKT_CLOSEREQ) { /* Step 13 */
if (dccp_rcv_closereq(sk, skb))
return 0;
goto discard;
- } else if (dh->dccph_type == DCCP_PKT_CLOSE) {
+ } else if (dh->dccph_type == DCCP_PKT_CLOSE) { /* Step 14 */
if (dccp_rcv_close(sk, skb))
return 0;
goto discard;
}
switch (sk->sk_state) {
- case DCCP_CLOSED:
- dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
- return 1;
-
case DCCP_REQUESTING:
queued = dccp_rcv_request_sent_state_process(sk, skb, dh, len);
if (queued >= 0)
@@ -680,8 +674,12 @@ int dccp_rcv_state_process(struct sock *
__kfree_skb(skb);
return 0;
- case DCCP_RESPOND:
case DCCP_PARTOPEN:
+ /* Step 8: if using Ack Vectors, mark packet acknowledgeable */
+ dccp_handle_ackvec_processing(sk, skb);
+ dccp_deliver_input_to_ccids(sk, skb);
+ /* fall through */
+ case DCCP_RESPOND:
queued = dccp_rcv_respond_partopen_state_process(sk, skb,
dh, len);
break;
^ permalink raw reply
* Re: [patch net-next-2.6 4/4] bridge: implement slave management operations
From: Jiri Pirko @ 2011-03-01 6:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, netdev, davem, kaber, fubar
In-Reply-To: <20110228144516.0174a9c8@nehalam>
Mon, Feb 28, 2011 at 11:45:16PM CET, shemminger@vyatta.com wrote:
>On Mon, 28 Feb 2011 14:17:29 -0800
>Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>
>> On Fri, 11 Feb 2011 16:23:47 +0100
>> Jiri Pirko <jpirko@redhat.com> wrote:
>>
>> >
>> > Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>
>Never mind, this is good. I was confusing slave with bridge initialization
>and netdevice ops with ethtool ops.
>
>Ethtool ops seems to be growing like weeds lately...
This was replaced by:
bridge: implement [add/del]_slave ops
never intended to be in ethtool
>
>
>
>--
^ 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