* Re: [PATCH net-next 1/1] ip6tnl/sit: drop packet if ECN present with not-ECT
From: David Miller @ 2012-11-28 16:37 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, shemminger
In-Reply-To: <1354021631-13602-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 27 Nov 2012 14:07:11 +0100
> This patch reports the change made by Stephen Hemminger in ipip and gre[6] in
> commit eccc1bb8d4b4 (tunnel: drop packet if ECN present with not-ECT).
>
> Goal is to handle RFC6040, Section 4.2:
>
> Default Tunnel Egress Behaviour.
> o If the inner ECN field is Not-ECT, the decapsulator MUST NOT
> propagate any other ECN codepoint onwards. This is because the
> inner Not-ECT marking is set by transports that rely on dropped
> packets as an indication of congestion and would not understand or
> respond to any other ECN codepoint [RFC4774]. Specifically:
>
> * If the inner ECN field is Not-ECT and the outer ECN field is
> CE, the decapsulator MUST drop the packet.
>
> * If the inner ECN field is Not-ECT and the outer ECN field is
> Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the
> outgoing packet with the ECN field cleared to Not-ECT.
>
> The patch takes benefits from common function added in net/inet_ecn.h.
>
> Like it was done for Xin4 tunnels, it adds logging to allow detecting broken
> systems that set ECN bits incorrectly when tunneling (or an intermediate
> router might be changing the header). Errors are also tracked via
> rx_frame_error.
>
> CC: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ewrk3: remove outdated comment
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: pebolle; +Cc: netdev, linux-kernel, richard.weinberger
In-Reply-To: <1354009714.1420.52.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Tue, 27 Nov 2012 10:48:34 +0100
> Remove an outdated comment, that should have been removed in the
> patch named "MODULE_PARM conversions" from early 2005.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ewrk3: silence GCC warning
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: pebolle; +Cc: netdev, linux-kernel, richard.weinberger
In-Reply-To: <1354009637.1420.50.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Tue, 27 Nov 2012 10:47:17 +0100
> Building ewrk3.o triggers this GCC warning:
> drivers/net/ethernet/dec/ewrk3.c: In function '__check_irq':
> drivers/net/ethernet/dec/ewrk3.c:1915:1: warning: return from incompatible pointer type [enabled by default]
>
> This can be trivially fixed by changing the 'irq' parameter from int to
> byte (which is an alias for unsigned char for module parameters).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix INTx ISR for interrupt behaviour on BE2
From: David Miller @ 2012-11-28 16:35 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <d856540b-bacc-45e3-a7cc-49e7febafb95@CMEXHTCAS1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 28 Nov 2012 11:20:02 +0530
> On BE2 chip, an interrupt may be raised even when EQ is in un-armed state.
> As a result be_intx()::events_get() and be_poll:events_get() can race and
> notify an EQ wrongly.
>
> Fix this by counting events only in be_poll(). Commit 0b545a629 fixes
> the same issue in the MSI-x path.
>
> But, on Lancer, INTx can be de-asserted only by notifying num evts. This
> is not an issue as the above BE2 behavior doesn't exist/has never been
> seen on Lancer.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: Nikolay Aleksandrov @ 2012-11-28 16:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andy, fubar
In-Reply-To: <20121128.112316.33060261620694469.davem@davemloft.net>
Actually I did see it from kernel/module.c and didn't come up with it
myself.
Anyway I will re-post with the change and will take a note for the future.
Thanks for the review
On 28/11/12 17:23, David Miller wrote:
> From: Nikolay Aleksandrov<nikolay@redhat.com>
> Date: Sat, 24 Nov 2012 13:21:15 +0100
>
>> @@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
>> arp_ip_count++) {
>> /* not complete check, but should be good enough to
>> catch mistakes */
>> - if (!isdigit(arp_ip_target[arp_ip_count][0])) {
>> + __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
>> + if (!isdigit(arp_ip_target[arp_ip_count][0])
>> + || ip == 0
>> + || ip == htonl(INADDR_BROADCAST)) {
> Please format this properly, put the connecting operators at the end,
> not the beginning, of the lines of the if statement, like so:
>
> if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
> ip == 0 ||
> ip == htonl(INADDR_BROADCAST)) {
>
> Where else did you see the layout you used? It's not a prevalent
> construct, so as far as I can tell you came up with it on your own.
>
> Please don't do this, and instead use existing practice as your guide.
>
> Thanks.
^ permalink raw reply
* Re: pull-request: can-next 2012-11-27
From: David Miller @ 2012-11-28 16:31 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <50B4807E.8010607@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 27 Nov 2012 09:57:34 +0100
> this is pull request is for net-next. Contains a patch by Andreas
> Larsson, which enables the sja1000 of driver to work under sparc.
> AnilKumar Ch contributed a patch to improve the c_can support under
> omap, Olivier Sobrie's patch brings support for the CAN/USB dongles
> from Kvaser. In a bunch of patches by me missing MODULE_ALIAS and/or
> MODULE_DEVICE_TABLE entries were added to the CAN drivers.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter updates for net (3.7-rc7)
From: David Miller @ 2012-11-28 16:30 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1353978185-3564-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 27 Nov 2012 02:03:04 +0100
> From: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Hi David,
>
> This update contains one patch to fix an overflow via the interface
> name attribute in the ipset infrastructure, from Florian Westphal.
>
> You can pull this change from:
>
> git://1984.lsi.us.es/nf master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: Move an interface to init_ne
From: Eric W. Biederman @ 2012-11-28 16:28 UTC (permalink / raw)
To: David Shwatrz; +Cc: Renato Westphal, netdev
In-Reply-To: <CAJJAcofHM+D8_2u-w5jPJZKfeA0A7QOxX1gxTQ2vOgx-L9aZhQ@mail.gmail.com>
David Shwatrz <dshwatrz@gmail.com> writes:
> But when I run "modprobe 8139too" on namespace1, a device named "eth1"
> is created on the initial network namespace and not on namesapce1.
> I expected that in such a case, a device named "eth0" will be created
> on namespace1, since it was called from namespace1. Or maybe modprobe
> does
> not consider the namespace from which it was called ?
modprobe has no concept of the namespace from which it was called.
Eric
^ permalink raw reply
* Re: [PATCH] vhost: fix length for cross region descriptor
From: David Miller @ 2012-11-28 16:27 UTC (permalink / raw)
To: mst; +Cc: netdev, jasowang, linux-kernel
In-Reply-To: <20121126155727.GA21716@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 26 Nov 2012 17:57:27 +0200
> If a single descriptor crosses a region, the
> second chunk length should be decremented
> by size translated so far, instead it includes
> the full descriptor length.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] irda: irttp: fix memory leak in irttp_open_tsap() error path
From: David Miller @ 2012-11-28 16:25 UTC (permalink / raw)
To: tt.rantala; +Cc: netdev, samuel, davej
In-Reply-To: <1353939404-19264-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Mon, 26 Nov 2012 16:16:44 +0200
> Cleanup the memory we allocated earlier in irttp_open_tsap() when we hit
> this error path. The leak goes back to at least 1da177e4
> ("Linux-2.6.12-rc2").
>
> Discovered with Trinity (the syscall fuzzer).
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: add Huawei E173
From: David Miller @ 2012-11-28 16:24 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1353859439-18260-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 25 Nov 2012 17:03:59 +0100
> The Huawei E173 is a QMI/wwan device which normally appear
> as 12d1:1436 in Linux. The descriptors displayed in that
> mode will be picked up by cdc_ether. But the modem has
> another mode with a different device ID and a slightly
> different set of descriptors. This is the mode used by
> Windows like this:
>
> 3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
> Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
> Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
> PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
>
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: David Miller @ 2012-11-28 16:23 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759675-30511-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Sat, 24 Nov 2012 13:21:15 +0100
> @@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
> arp_ip_count++) {
> /* not complete check, but should be good enough to
> catch mistakes */
> - if (!isdigit(arp_ip_target[arp_ip_count][0])) {
> + __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
> + if (!isdigit(arp_ip_target[arp_ip_count][0])
> + || ip == 0
> + || ip == htonl(INADDR_BROADCAST)) {
Please format this properly, put the connecting operators at the end,
not the beginning, of the lines of the if statement, like so:
if (!isdigit(arp_ip_target[arp_ip_count][0]) ||
ip == 0 ||
ip == htonl(INADDR_BROADCAST)) {
Where else did you see the layout you used? It's not a prevalent
construct, so as far as I can tell you came up with it on your own.
Please don't do this, and instead use existing practice as your guide.
Thanks.
^ permalink raw reply
* Re: TCP and reordering
From: David Woodhouse @ 2012-11-28 16:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vijay Subramanian, David Miller, saku, rick.jones2, netdev
In-Reply-To: <1354118982.14302.356.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Wed, 2012-11-28 at 08:09 -0800, Eric Dumazet wrote:
> My point was that if you limit number of in flight packet to 1,
> its relatively easy to add glue in the priv dev data, so that you chain
> the destructor without adding yet another fields in all skbs.
Hm, true. I do think we'll need to be able to have at least two packets
in-flight though. There's a fair amount of network stack to be navigated
by a skb once we release it, in the PPPoE and especially L2TP cases. The
latency involved in that, if we only allow one packet at a time, will
surely be noticeable. You're basically guaranteeing that a 'TX done' IRQ
won't have another packet in the device's queue ready to send, and you
won't be able to saturate the uplink.
I suppose your principle applies even for more than one skb at a time;
we can have an array of {skb, old_destructor} tuples in our per-channel
private state, rather than having to keep it with the skb itself... but
that's slightly less simple.
I'll go and knock something up...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH] bonding: fix race condition in bonding_store_slaves_active
From: David Miller @ 2012-11-28 16:21 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759595-30452-1-git-send-email-nikolay@redhat.com>
Some bonding developer reviews would be appreciated.
^ permalink raw reply
* Re: [PATCH] bonding: fix miimon and arp_interval delayed work race conditions
From: David Miller @ 2012-11-28 16:21 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1353759471-30323-1-git-send-email-nikolay@redhat.com>
Bonding folks, please review.
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-28 16:20 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121123210319.GA15775@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Fri, 23 Nov 2012 22:03:19 +0100
> This patch turns QFQ into QFQ+, a variant of QFQ that provides the
> following two benefits: 1) QFQ+ is faster than QFQ, 2) differently
> from QFQ, QFQ+ correctly schedules also non-leaves classes in a
> hierarchical setting. A detailed description of QFQ+, plus a
> performance comparison with DRR and QFQ, can be found in [1].
>
> [1] P. Valente, "Reducing the Execution Time of Fair-Queueing Schedulers"
> http://algo.ing.unimo.it/people/paolo/agg-sched/agg-sched.pdf
>
> Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Applied, thanks.
^ permalink raw reply
* Re: TCP and reordering
From: Benjamin LaHaise @ 2012-11-28 16:19 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Vijay Subramanian, David Miller, saku, rick.jones2,
netdev
In-Reply-To: <1354117635.21562.63.camel@shinybook.infradead.org>
On Wed, Nov 28, 2012 at 03:47:15PM +0000, David Woodhouse wrote:
> On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> > BQL is nice for high speed adapters.
>
> For adapters with hugely deep queues, surely? There's a massive
> correlation between the two, of course ??? but PPP over L2TP or PPPoE
> ought to be included in the classification, right?
Possibly, but there are many setups where PPPoE/L2TP do not connect to
the congested link directly.
> > For slow one, you always can stop the queue for each packet given to
> > start_xmit()
> >
> > And restart the queue at TX completion.
>
> Well yes, but only if we get notified of TX completion.
>
> It's simple enough for the tty-based channels, and we can do it with a
> vcc->pop() function for PPPoATM. But for PPPoE and L2TP, how do we do
> it? We can install a skb destructor... but then we're stomping on TSQ's
> use of the destructor by orphaning it too soon.
>
> I'm pondering something along the lines of
>
> if (skb->destructor) {
> newskb = skb_clone(skb, GFP_KERNEL);
> if (newskb) {
> skb_shinfo(newskb) = skb;
> skb = newskb;
> }
> }
> skb_orphan(skb);
> skb->destructor = ppp_chan_tx_completed;
>
>
> ... and then ppp_chan_tx_completed can also destroy the original skb
> (and hence invoke TSQ's destructor too) when the time comes. And in the
> (common?) case where we don't have an existing destructor, we don't
> bother with the skb_clone.
This sort of chaining of destructors is going to be very expensive in
terms of CPU cycles. If this does get implemented, please ensure there is
a way to turn it off. Specifically, I'm thinking of the access concetrator
roles for BRAS. In many wholesale ISP setups, there are many incoming
sessions coming in over a high speed link (gigabit or greater) for which
the access concentrator (LAC/LNS in L2TP speak) has no idea of the
bandwidth of the link actually facing the customer. Such systems are
usually operated in a way to avoid ever congesting the aggregation network.
In such setups, BQL on the L2TP/PPPoE interface only serves to increase CPU
overhead.
That said, if there is local congestion, the benefits of BQL would be
worthwhile to have.
> But I wish there was a nicer way to chain destructors. And no, I don't
> count what GSO does. We can't use the cb here anyway since we're passing
> it down the stack.
I think all the tunneling protocols are going to have the same problem
here, so it deserves some thought about how to tackle the issue in a
generic way without incurring a large amount of overhead. This exact
problem is one of the reasons multilink PPP often doesn't work well over
L2TP or PPPoE as compared to its behaviour over ttys.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH 0/6] smsc75xx enhancements
From: David Miller @ 2012-11-28 16:17 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1354118391-22666-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Wed, 28 Nov 2012 15:59:44 +0000
> This patchset implements wake on PHY (link up or link down) and
> USB dynamic autosuspend for smsc75xx.
>
> Please consider all for net-next.
All applied, thanks Steve.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Can set maxrate only for TC0
From: David Miller @ 2012-11-28 16:16 UTC (permalink / raw)
To: amirv; +Cc: ogerlitz, oren, netdev
In-Reply-To: <1354102995-27305-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Wed, 28 Nov 2012 13:43:15 +0200
> Had a typo in memcpy.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: Error in calculation of RTTvar
From: David Miller @ 2012-11-28 16:13 UTC (permalink / raw)
To: vyasevich; +Cc: netdev
In-Reply-To: <1354115909-24172-1-git-send-email-vyasevich@gmail.com>
From: vyasevich@gmail.com
Date: Wed, 28 Nov 2012 10:18:29 -0500
> From: Schoch Christian <e0326715@student.tuwien.ac.at>
>
> The calculation of RTTVAR involves the subtraction of two unsigned
> numbers which
> may causes rollover and results in very high values of RTTVAR when RTT > SRTT.
> With this patch it is possible to set RTOmin = 1 to get the minimum of RTO at
> 4 times the clock granularity.
>
> Change Notes:
>
> v2)
> *Replaced abs() by abs64() and long by __s64, changed patch
> description.
>
> Signed-off-by: Christian Schoch <e0326715@student.tuwien.ac.at>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: Sridhar Samudrala <sri@us.ibm.com>
> CC: Neil Horman <nhorman@tuxdriver.com>
> CC: linux-sctp@vger.kernel.org
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* [patch net] team: fix hw_features setup
From: Jiri Pirko @ 2012-11-28 16:13 UTC (permalink / raw)
To: netdev; +Cc: davem
Do this in the same way bonding does. This fixed setup resolves performance
issues when using some cards with certain offloading.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/team/team.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index d44cca3..ad86660 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1794,10 +1794,12 @@ static void team_setup(struct net_device *dev)
dev->features |= NETIF_F_LLTX;
dev->features |= NETIF_F_GRO;
- dev->hw_features = NETIF_F_HW_VLAN_TX |
+ dev->hw_features = TEAM_VLAN_FEATURES |
+ NETIF_F_HW_VLAN_TX |
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER;
+ dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
dev->features |= dev->hw_features;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
From: David Miller @ 2012-11-28 16:12 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590596-12216-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:23:16 +0200
> Consider the following program, that sets the second argument to the
> sendto() syscall incorrectly:
...
> We get -ENOMEM:
>
> $ strace -e sendto ./demo
> sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ENOMEM (Cannot allocate memory)
>
> Propagate the error code from sctp_user_addto_chunk(), so that we will
> tell user space what actually went wrong:
>
> $ strace -e sendto ./demo
> sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EFAULT (Bad address)
>
> Noticed while running Trinity (the syscall fuzzer).
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
From: David Miller @ 2012-11-28 16:11 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1354024906-1925-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Tue, 27 Nov 2012 16:01:46 +0200
> Trinity (the syscall fuzzer) discovered a memory leak in SCTP,
> reproducible e.g. with the sendto() syscall by passing invalid
> user space pointer in the second argument:
...
> As far as I can tell, the leak has been around since ~2003.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/6] qlcnic: refactor 82xx adapter driver
From: David Miller @ 2012-11-28 16:10 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1354113271-23850-1-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Wed, 28 Nov 2012 09:34:25 -0500
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Refactor 82xx adapter driver to create new files for:
> Data path routines.
> Sysfs interface routines.
> Hardware register dump utility.
>
> We are refactoring the driver code to add support for a new adapter.
> Existing 82xx driver code has coding style issues.
> Each physical refactoring patch is followed by a seperate patch
> to fix the style issues in the newly created file.
>
> Patches in the series are listed below.
> 0001-qlcnic-create-file-qlcnic_io.c-for-datapath-routines.patch
> 0002-qlcnic-fix-coding-style-issues-in-qlcnic_io.c.patch
> 0003-qlcnic-create-file-qlcnic_sysfs.c-for-sysfs-routines.patch
> 0004-qlcnic-fix-style-issues-in-qlcnic_sysfs.c-file.patch
> 0005-qlcnic-create-file-qlcnic_minidump.c-for-dump-utilit.patch
> 0006-qlcnic-fix-coding-style-issues-in-qlcnic_minidump.c.patch
>
> Please apply to net-next.
All applied, thanks.
^ permalink raw reply
* Re: TCP and reordering
From: Eric Dumazet @ 2012-11-28 16:09 UTC (permalink / raw)
To: David Woodhouse
Cc: Vijay Subramanian, David Miller, saku, rick.jones2, netdev
In-Reply-To: <1354117635.21562.63.camel@shinybook.infradead.org>
On Wed, 2012-11-28 at 15:47 +0000, David Woodhouse wrote:
> On Wed, 2012-11-28 at 04:52 -0800, Eric Dumazet wrote:
> > BQL is nice for high speed adapters.
>
> For adapters with hugely deep queues, surely? There's a massive
> correlation between the two, of course — but PPP over L2TP or PPPoE
> ought to be included in the classification, right?
>
> > For slow one, you always can stop the queue for each packet given to
> > start_xmit()
> >
> > And restart the queue at TX completion.
>
> Well yes, but only if we get notified of TX completion.
>
> It's simple enough for the tty-based channels, and we can do it with a
> vcc->pop() function for PPPoATM. But for PPPoE and L2TP, how do we do
> it? We can install a skb destructor... but then we're stomping on TSQ's
> use of the destructor by orphaning it too soon.
>
> I'm pondering something along the lines of
>
> if (skb->destructor) {
> newskb = skb_clone(skb, GFP_KERNEL);
> if (newskb) {
> skb_shinfo(newskb) = skb;
> skb = newskb;
> }
> }
> skb_orphan(skb);
> skb->destructor = ppp_chan_tx_completed;
>
>
> ... and then ppp_chan_tx_completed can also destroy the original skb
> (and hence invoke TSQ's destructor too) when the time comes. And in the
> (common?) case where we don't have an existing destructor, we don't
> bother with the skb_clone.
>
> But I wish there was a nicer way to chain destructors. And no, I don't
> count what GSO does. We can't use the cb here anyway since we're passing
> it down the stack.
>
My point was that if you limit number of in flight packet to 1,
its relatively easy to add glue in the priv dev data, so that you chain
the destructor without adding yet another fields in all skbs.
At start_xmit() do the following instead of skb_orphan(skb)
if (skb->destructor) {
BUG_ON(priv->save_destructor);
priv->save_destructor = skb->destructor;
priv->save_sk = skb->sk;
skb->sk = &priv->fake_sk;
}
skb->destructor = my_destructor;
/* stop the queue */
...
}
void my_destructor(struct sk_buff *skb)
{
struct .... *priv = container_of(skb, struct ..., priv.fake_sk);
skb->sk = skb->save_sk;
priv->save_destructor(skb);
priv->save_destructor = NULL;
/* restart the queue */
...
}
Something like that.
^ 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