* [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
From: Jason Luan @ 2013-10-16 17:22 UTC (permalink / raw)
To: xen-devel, netdev
Cc: annie.li, wei.liu2, ian.campbell, Jason Luan, david.vrabel
time_after_eq() only works if the delta is < MAX_ULONG/2.
If netfront sends at a very low rate, the time between subsequent calls
to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for
timer_after_eq() will be incorrect. Credit will not be replenished and
the guest may become unable to send (e.g., if prior to the long gap, all
credit was exhausted).
We should add the scenario which now beyond next_credit+MAX_UNLONG/2. Because
the fact now must be not before than expire, time_before(now, expire) == true
will verify the scenario.
time_after_eq(now, next_credit) || time_before (now, expire)
==
!time_in_range_open(now, expire, next_credit)
Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
drivers/net/xen-netback/netback.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index f3e591c..31eedaf 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1194,8 +1194,11 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
if (timer_pending(&vif->credit_timeout))
return true;
- /* Passed the point where we can replenish credit? */
- if (time_after_eq(now, next_credit)) {
+ /* Credit should be replenished when now does not fall into the
+ * range from expires to next_credit, and time_in_range_open()
+ * is used to verify whether this case happens.
+ */
+ if (!time_in_range_open(now, vif->credit_timeout.expires, next_credit)) {
vif->credit_timeout.expires = now;
tx_add_credit(vif);
}
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH net-next] tcp: remove redundant code in __tcp_retransmit_skb()
From: Yuchung Cheng @ 2013-10-16 17:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neal Cardwell, David Miller, netdev, Eric Dumazet
In-Reply-To: <1381941843.2045.132.camel@edumazet-glaptop.roam.corp.google.com>
On Wed, Oct 16, 2013 at 12:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-10-16 at 12:36 -0400, Neal Cardwell wrote:
>> Remove the specialized code in __tcp_retransmit_skb() that tries to trim
>> any ACKed payload preceding a FIN before we retransmit (this was added
>> in 1999 in v2.2.3pre3). This trimming code was made unreachable by the
>> more general code added above it that uses tcp_trim_head() to trim any
>> ACKed payload, with or without a FIN (this was added in "[NET]: Add
>> segmentation offload support to TCP." in 2002 circa v2.5.33).
>>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Yuchung Cheng <ycheng@google.com>
>> ---
>> net/ipv4/tcp_output.c | 15 ---------------
>> 1 file changed, 15 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
>
>
^ permalink raw reply
* Re: [PATCH RFC 3/5] net:stmmac: ensure we reclaim all dirty descriptors.
From: Sergei Shtylyov @ 2013-10-16 17:46 UTC (permalink / raw)
To: Jimmy Perchet; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1381937052-8999-4-git-send-email-jimmy.perchet@parrot.com>
Hello.
On 10/16/2013 07:24 PM, Jimmy Perchet wrote:
> On low speed link (10MBit/s), some TX descriptors can remain dirty
> if the tx coalescence timer expires before they were treated. Re-arm timer
> in this case.
> Signed-off-by: Jimmy Perchet <jimmy.perchet@parrot.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 0015175..af04b5d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1284,8 +1284,12 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> p = priv->dma_tx + entry;
>
> /* Check if the descriptor is owned by the DMA. */
> - if (priv->hw->desc->get_tx_owner(p))
> + if (priv->hw->desc->get_tx_owner(p)) {
> + /* Be sure to harvest remaining descriptor. */
> + mod_timer(&priv->txtimer,
> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
The continuation line should stat right under &, according to thenetworking
coding style.
WBR, Sergei
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Jamal Hadi Salim @ 2013-10-16 17:49 UTC (permalink / raw)
To: vyasevic, Stephen Hemminger; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <525EC8AF.6000902@redhat.com>
On 10/16/13 13:11, Vlad Yasevich wrote:
> On 10/16/2013 09:54 AM, Jamal Hadi Salim wrote:
>
>
> This was to display or filter out virtual function data.
>
Stephen explained - and it seems to make sense (working around
netlink weaknesses). It could be made more generic.
> I probably doesn't need to use this as we want the bridge data, not the
> VF data stored as part of PF interface.
>
I think we need some filtering in the kernel. As it stands today,
unfortunately you get everything ;-> I was suprised at the amount of
data i get from the kernel these days when i ask for a simple netdev
info (I think no less than 1K per netdev; everything from /proc entries
from some bread crumbs i dont see any use for.
>> - get attributes for all bridge ports for bridge br-blah (not there)
>> you could also use the ifindex of br-blah here instead
>
> This would be usefull.
>
Its a usability improvement.
We still have the ifi->ifindex available. It could be used to signal
which bridge device's ports i want.
But then i get _all_ the ports for that bridge.
>
>
> You can already do this with:
>
> ip link set dev ethX master brX
>
Yes, I know - it sucks from a usability pov.
cheers,
jamal
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Eric Dumazet @ 2013-10-16 18:35 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: vyasevic, Stephen Hemminger, Stephen Hemminger,
netdev@vger.kernel.org
In-Reply-To: <525ED1AE.7050101@mojatatu.com>
On Wed, 2013-10-16 at 13:49 -0400, Jamal Hadi Salim wrote:
> I think we need some filtering in the kernel. As it stands today,
> unfortunately you get everything ;-> I was suprised at the amount of
> data i get from the kernel these days when i ask for a simple netdev
> info (I think no less than 1K per netdev; everything from /proc entries
> from some bread crumbs i dont see any use for.
By the way, "ip link show dev xxxx" seems to dump all devices info from
the kernel...
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Stephen Hemminger @ 2013-10-16 18:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jamal Hadi Salim, vyasevic, Stephen Hemminger,
netdev@vger.kernel.org
In-Reply-To: <1381948550.2045.136.camel@edumazet-glaptop.roam.corp.google.com>
On Wed, 16 Oct 2013 11:35:50 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-10-16 at 13:49 -0400, Jamal Hadi Salim wrote:
>
> > I think we need some filtering in the kernel. As it stands today,
> > unfortunately you get everything ;-> I was suprised at the amount of
> > data i get from the kernel these days when i ask for a simple netdev
> > info (I think no less than 1K per netdev; everything from /proc entries
> > from some bread crumbs i dont see any use for.
>
> By the way, "ip link show dev xxxx" seems to dump all devices info from
> the kernel...
>
>
As I remember.
The problem is that according to original netlink design there is supposed to
be a NLM_F_MATCH, but it seems it never got implemented right, and the legacy
of breaking applications keeps it from happening.
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Vlad Yasevich @ 2013-10-16 18:50 UTC (permalink / raw)
To: Eric Dumazet, Jamal Hadi Salim
Cc: Stephen Hemminger, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <1381948550.2045.136.camel@edumazet-glaptop.roam.corp.google.com>
On 10/16/2013 02:35 PM, Eric Dumazet wrote:
> On Wed, 2013-10-16 at 13:49 -0400, Jamal Hadi Salim wrote:
>
>> I think we need some filtering in the kernel. As it stands today,
>> unfortunately you get everything ;-> I was suprised at the amount of
>> data i get from the kernel these days when i ask for a simple netdev
>> info (I think no less than 1K per netdev; everything from /proc entries
>> from some bread crumbs i dont see any use for.
>
> By the way, "ip link show dev xxxx" seems to dump all devices info from
> the kernel...
>
>
Right. ip link show is dumb. It asks for info from all devices and
then filters based on the device you asked for, but the filtering
is done in iproute instead of the kernel.
brdige command inherited this through code re-use.
-vlad
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Jamal Hadi Salim @ 2013-10-16 19:02 UTC (permalink / raw)
To: vyasevic, Eric Dumazet
Cc: Stephen Hemminger, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <525EE00A.20209@redhat.com>
On 10/16/13 14:50, Vlad Yasevich wrote:
> Right. ip link show is dumb. It asks for info from all devices and
> then filters based on the device you asked for, but the filtering
> is done in iproute instead of the kernel.
>
That maybe small flaw in iproute2 - but there's no issue in the kernel.
You can send an ifi and specify the proper ifindex of choice.
But you cant do the same with bridge.
Thats what i was whining to Stephen about. I get every
bridge port with no exception and there's no way to specify one
(the ifi ifindex is never used).
Think 20K bridge ports - each giving me 1K of data ...
scalability problem
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/3] ipvs: avoid rcu_barrier during netns cleanup
From: Julian Anastasov @ 2013-10-16 19:52 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang
In-Reply-To: <20131016104306.GA10288@localhost>
Hello,
On Wed, 16 Oct 2013, Pablo Neira Ayuso wrote:
> I can enqueue this fix to nf if you like. No need to resend, I can
> manually apply.
>
> Let me know.
It is not critical. I waited weeks the net tree to be
copied into net-next because it collides with the recent
"ipvs: make the service replacement more robust" change in
net tree :) But if a rcu_barrier in the netns cleanup looks
scary enough you can push it to nf. IMHO, it just adds
unneeded delay there.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Eric W. Biederman @ 2013-10-16 19:53 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: Stephen Hemminger, David Miller, yamato, netdev
In-Reply-To: <525E659C.3000305@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 15/10/2013 22:34, Eric W. Biederman a écrit :
>> For IFLA_NET_NS_FD not that I know of.
>>
>> Mostly it is doable but there are some silly cases.
>> - Do we need to actually implement SCM_RIGHTS to prevent people
>> accepting file-descriptors unknowingly and hitting their file
>> descriptor limits.
>>
>> In which case we need to call the attribute IFLA_NET_NS_SCM_FD
>> so we knew it was just an index into the passed file descriptors.n
>>
>> - Do we need an extra permission check to prevent keeping a network
>> namespace alive longer than necessary? Aka there are some permission
>> checks opening and bind mounting /proc/<pid>/ns/net do we need
>> a similar check. Perhaps we would need to require CAP_NET_ADMIN over
>> the target network namespace.
>>
>> Beyond that it is just the logistics to open what is essentially
>> /proc/<pid>/ns/net and add it to the file descriptor table of the
>> requesting process. Exactly which mount of proc we are going to
>> find the appropriate file to open I don't know.
>>
>> It isn't likely to be lots of code but it is code that the necessary
>> infrastructure is not in place for, and a bunch of moderately hairy
>> corner cases to deal with.
> Got it. This doesn't seems the simpliest/best way to resolve this pb.
> Can we not introduce another identifier (something like IFLA_NET_NS_ID),
> which will not have such constraint?
> inode is unique on the system, why not using it as an opaque value to
> identitfy the netns (like 'ip netns identify' do)?
The age old question why can't we have global identifiers for
namespaces?
The answer is that I don't want to implement a namespace for namespaces.
While the proc inode does work today across different mounts of proc, I
reserve the right at some future date (if it solves a technical problem)
to give each namespace a different inode number in each different mount
of proc. So the inode number is not quite the unique identifier you
want. The inode number is a close as I am willing to get to a namespace
of namespaces.
I think the simplest solution is to just not worry about which namespace
the other half of a veth pair is in. But I have not encountered the
problem where I need to know exactly which namespace we are worrying
about.
Global identifiers are easy until you hit the cases where they make
things impossible.
Eric
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Jamal Hadi Salim @ 2013-10-16 20:19 UTC (permalink / raw)
To: vyasevic, Eric Dumazet
Cc: Stephen Hemminger, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <525EE2AC.50002@mojatatu.com>
And another little glitch, iflink specifies
[IFLA_AF_SPEC] = {
[AF_INET] = {
[IFLA_INET_CONF] = ...,
},
[AF_INET6] = {
[IFLA_INET6_FLAGS] = ...,
[IFLA_INET6_CONF] = ...,
}
But then bridge hijacks it and specifies:
[IFLA_AF_SPEC] = {
[IFLA_BRIDGE_FLAGS]
[IFLA_BRIDGE_MODE]
[IFLA_BRIDGE_VLAN_INFO]
}
Was that intended as:
[IFLA_AF_SPEC] = {
[AF_BRIDGE] = {
[IFLA_BRIDGE_FLAGS]
[IFLA_BRIDGE_MODE]
[IFLA_BRIDGE_VLAN_INFO]
}
}
Now granted that bridging uses PF_BRIDGE as the family and iflink uses
PF_UNSPEC - but i do think this one is polluting the namespace.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v2.43 0/5] MPLS actions and matches
From: Jesse Gross @ 2013-10-16 20:21 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Ravi K, netdev,
Isaku Yamahata
In-Reply-To: <20131016035530.GA29165-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On Tue, Oct 15, 2013 at 8:55 PM, Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Oct 10, 2013 at 09:31:41AM +0900, Simon Horman wrote:
>> I believe this series addresses the feedback that each of you
>> gave with regards to recent previous postings of this patch-set.
>> I'm wondering if you could find some time to review it.
>
> I'm waiting for an ack from Jesse, then I'm going to do a final pass and
> I hope to commit this series at this point. I see some ways that we can
> improve MPLS support afterward but I don't see any blockers.
I guess that we had a deadlock as I was waiting for you. I though that
maybe you would commit the rest of the userspace patches and then I
would just pick up the last two.
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Vlad Yasevich @ 2013-10-16 20:22 UTC (permalink / raw)
To: Jamal Hadi Salim, Eric Dumazet
Cc: Stephen Hemminger, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <525EF4E7.1030003@mojatatu.com>
On 10/16/2013 04:19 PM, Jamal Hadi Salim wrote:
>
> And another little glitch, iflink specifies
>
> [IFLA_AF_SPEC] = {
> [AF_INET] = {
> [IFLA_INET_CONF] = ...,
> },
> [AF_INET6] = {
> [IFLA_INET6_FLAGS] = ...,
> [IFLA_INET6_CONF] = ...,
> }
>
> But then bridge hijacks it and specifies:
> [IFLA_AF_SPEC] = {
> [IFLA_BRIDGE_FLAGS]
> [IFLA_BRIDGE_MODE]
> [IFLA_BRIDGE_VLAN_INFO]
> }
>
> Was that intended as:
>
> [IFLA_AF_SPEC] = {
> [AF_BRIDGE] = {
> [IFLA_BRIDGE_FLAGS]
> [IFLA_BRIDGE_MODE]
> [IFLA_BRIDGE_VLAN_INFO]
> }
> }
>
> Now granted that bridging uses PF_BRIDGE as the family and iflink uses
> PF_UNSPEC - but i do think this one is polluting the namespace.
>
Yes, I know about that one. BRIDGE_FLAGS started the polution and then
we continued it with the other attributes....
-vlad
> cheers,
> jamal
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-16 20:22 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <20131016143246.GB18135@order.stressinduktion.org>
Hello,
On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
> On Wed, Oct 16, 2013 at 10:27:47AM +0300, Julian Anastasov wrote:
> >
> > I don't know the IPv6 routing but if we find a way
> > to keep the desired nexthop in rt6i_gateway and to add
> > RTF_GATEWAY checks here and there such solution would be more
> > general. FLOWI_FLAG_KNOWN_NH flag can help, if needed.
>
> I thought about this yesterday but did not see an easy way. How does the IPv4
> implementation accomplish this?
In IPv4 rt->rt_flags has no bit to indicate if the route
is via gateway (like RTF_GATEWAY in IPv6). We added rt_uses_gateway
for this purpose.
In the default case, rt_gateway may contain 0 if we return
cached result, eg. when target is part of a local subnet.
Then IPVS/TEE/RAW can request valid rt_gateway, even with the price
of a cloned result, so that rt_gateway can remember the requested
nexthop which may differ from daddr.
> ipvs caches the dst in its own infrastructure, so we need to be sure we don't
> disconnect this dst from the ipv6 routing table, otherwise ip6_dst_check won't
> recognize when relookups should be done. Playing games with RTF_GATEWAY seems
> dangerous then.
dst_check works for IPVS. There is a problem only
with the recent changes that moved the indication for PMTU
change from dst_check to dst_mtu() calls. But this is safe
for IPVS, it handles FRAG_NEEDED for the tunneling mode itself.
Initially, I thought IPv6 stores zeroes in rt6i_gateway.
But now I see rt6_alloc_cow() to be called for the case I assumed
to fail - when no gateway is used.
So, I'll try to test the IPVS case in the following 1-2 days
and will report after adding some printks. If xt_TEE has
the same problem then it should not be IPVS-specific. RAW not
tested yet.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: Greg KH @ 2013-10-16 20:24 UTC (permalink / raw)
To: Enrico Mioso
Cc: davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel, Antonella Pellizzari
In-Reply-To: <1381842408-10800-2-git-send-email-mrkiko.rs@gmail.com>
On Tue, Oct 15, 2013 at 03:06:48PM +0200, Enrico Mioso wrote:
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
> Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
From: Giuseppe CAVALLARO @ 2013-10-16 20:29 UTC (permalink / raw)
To: Romain Baeriswyl; +Cc: David S. Miller, netdev, linux-kernel, Christian Ruppert
In-Reply-To: <808496140.2212.1381694572197.JavaMail.root@abilis.com>
Hello Romain
On 10/13/2013 10:02 PM, Romain Baeriswyl wrote:
> Hello Guiseppe,
>
> Thanks for your answer. Please find below some details and answers.
>
>>> In order to avoid system overload, the clock RXC from the Phy
>>> should not be
>>> stopped when in LPI mode.
>>>
>>> With the RTL8211E PHY which support EEE mode and with Apple Airport
>>> Extreme that
>>> supports it also, the kernel get frozen as soon as some Ethernet
>>> transfers are
>>
>>
>> hmm, I have a board with this transceiver so I could do some tests
>> this could take a while, unfortunately.
>>
>>> on-going. System seems to be overloaded with too many interrupts.
>>> The 'top'
>>> command reports often around ~80% irq.
>>
>> do you mean lpi mac interrupts?
>
> By disabling the LPI mode with ethtool --set-eee eth0 eee off, the
> interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and
> irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue
> to put the RX path in LPI mode.
>
> Only way I found to get ride of the overload is to keep the RX_CLK running
> in LPI mode. In this configuration, the RX link still continue to go in
> LPI mode and the two above counters continue to run.
>
>>>
>>> By letting the RXC clock running even in LPI mode as proposed
>>> below, the issue
>>> seems solved. Is it the right way to proceed?
>>
>> For EEE capability, RX_CLK may be halted for this reason i used it as
>> default in the stmmac and never seen your issue.
>>
>>>
>>> What is the power impact to not stop RXC in LPI mode?
>>
>> I can point you to "22.2.2.8a Receive direction LPI transition"
>> in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
>> in LPI mode.
>
> Actually the PHY "may" stop RX_CLK.
Another option it could be add a new parameter to enable/disable it.
We can decide a parameter for the stmmac or something for ethtool.
>
>>
>> May I suspect some issues on your HW? or disable it with ethtool
>>
>
> Yes, it could be HW issue. It would be very useful if you could reproduce
> the setup using a SoC with "DesignWare Cores Ethernet MAC" core,
> the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between
> the controller and the PHY.
>
> Which Ethernet switch or router did you use to test the EEE mode?
when I tested EEE I connected with P2P two STi boards.
You can test it too.
> I may try these equipments as well.
>
peppe
^ permalink raw reply
* Re: [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation
From: Giuseppe CAVALLARO @ 2013-10-16 20:37 UTC (permalink / raw)
To: Jimmy Perchet; +Cc: netdev
In-Reply-To: <1381937052-8999-1-git-send-email-jimmy.perchet@parrot.com>
Hello Jimmy
On 10/16/2013 5:24 PM, Jimmy Perchet wrote:
> Hello,
>
> I began using Synopsys IP few weeks ago and figured out that jumbo frames
> are not well supported by stmmac driver.
I tested jumbo on chips w/o enhanced some time ago, so welcome further
tests as you did (maybe on new chips).
>
> This patch series addresses several issues which prevent them from working
> properly :
> *(1/5) Threshold dma mode is needed on rx path if jumbo frames are expected.
hmm, this depends on the HW. In the past I used HW with a Fifo that is
16KiB for rx buffers and 8KiB for tx.
So this could be managed according to these sizes I guess...
>
> *(2/5) RX buffers are not allocated with the needed size because
> priv->dma_buf_sz is updated too late (i.e. after stmmac_init_rx_buffers call)
I'll look at the patch in detail
>
> *(3/5) On low speed link (10MBit/s), some TX descriptors can remain dirty
> if the tx coalescence timer expires before they were treated. Re-arm timer
> in this case.
hmm not clear to me, let me look at the patch. I hope the link should
not impact... never seen on my side.
>
> *(4/5) There is several confusions regarding descriptor's max buffer size,
> typically the "-1" is often forgotten.
also for this I need to look at the patch
> *(4/5) Jumbo frames' last descriptor is never "closed", resulting in truncated
> frames transfer.
it sounds to be a bug... let me check
> *(4/5) Frags could not be jumbo.
> Regarding these last points, I didn't find simpler way than writing
> new "prepare frame" functions for both ring and chain mode and update
> xmit function accordingly.
it is strange and not clear too. At any rate, both modes must be
supported
>
> The last patch is not related to jumbo frames but concern a possible
> optimisation :
> *(5/5) Tx descriptor's cleanup and preparation are serialized, which is not
> necessary and decrease performance. In addition TX descriptor's cleanup is
> performed on NET_-RX- softirq, this is confusing.
> By taking care of "cur_tx" and "dirty_tx" it is possible to avoid serialization
> and defer cleanup in workqueue.
> On my smp embedded system, with 1Gbit/s link which is cpu bound, it increases
> througput by about 90MBit/s (400MBit/s to 490MBit/s).
This sounds another good point, let me enter in the patch
BR
Peppe
>
>
> Best Regards,
> Jimmy Perchet
>
> Jimmy Perchet (5):
> net:stmmac: set threshold/store and forward mode according to mtu
> size.
> net:stmmac: fix rx buffer allocation.
> net:stmmac: ensure we reclaim all dirty descriptors.
> net:stmmac: fix jumbo frame handling.
> net:stmmac: asynchronous tx_clean
>
> drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 99 +++++-----
> drivers/net/ethernet/stmicro/stmmac/common.h | 6 +
> drivers/net/ethernet/stmicro/stmmac/descs_com.h | 8 +-
> drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 6 +
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 6 +
> drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 90 ++++-----
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 219 +++++++++++++---------
> 8 files changed, 233 insertions(+), 207 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 5/5] net: rfkill: gpio: add ACPI support
From: Rafael J. Wysocki @ 2013-10-16 20:55 UTC (permalink / raw)
To: Heikki Krogerus
Cc: John W. Linville, Johannes Berg, Rhyland Klein, linux-acpi,
linux-wireless, netdev, Mika Westerberg
In-Reply-To: <1381920823-15403-6-git-send-email-heikki.krogerus@linux.intel.com>
On Wednesday, October 16, 2013 01:53:43 PM Heikki Krogerus wrote:
> Including ACPI ID for Broadcom GPS receiver BCM4752.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> net/rfkill/rfkill-gpio.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
> index 2dd78c6..5620d3c 100644
> --- a/net/rfkill/rfkill-gpio.c
> +++ b/net/rfkill/rfkill-gpio.c
> @@ -24,6 +24,8 @@
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
> +#include <linux/acpi_gpio.h>
>
> #include <linux/rfkill-gpio.h>
>
> @@ -70,6 +72,23 @@ static const struct rfkill_ops rfkill_gpio_ops = {
> .set_block = rfkill_gpio_set_power,
> };
>
> +static int rfkill_gpio_acpi_probe(struct device *dev,
> + struct rfkill_gpio_data *rfkill)
> +{
> + const struct acpi_device_id *id;
> +
> + id = acpi_match_device(dev->driver->acpi_match_table, dev);
> + if (!id)
> + return -ENODEV;
> +
> + rfkill->name = dev_name(dev);
> + rfkill->type = (unsigned)id->driver_data;
> + rfkill->reset_gpio = acpi_get_gpio_by_index(dev, 0, NULL);
> + rfkill->shutdown_gpio = acpi_get_gpio_by_index(dev, 1, NULL);
> +
> + return 0;
> +}
> +
> static int rfkill_gpio_probe(struct platform_device *pdev)
> {
> struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
> @@ -82,7 +101,11 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
> if (!rfkill)
> return -ENOMEM;
>
> - if (pdata) {
> + if (ACPI_HANDLE(&pdev->dev)) {
> + ret = rfkill_gpio_acpi_probe(&pdev->dev, rfkill);
> + if (ret)
> + return ret;
> + } else if (pdata) {
> clk_name = pdata->power_clk_name;
> rfkill->name = pdata->name;
> rfkill->type = pdata->type;
> @@ -170,12 +193,18 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct acpi_device_id rfkill_acpi_match[] = {
> + { "BCM4752", RFKILL_TYPE_GPS },
> + { },
> +};
> +
> static struct platform_driver rfkill_gpio_driver = {
> .probe = rfkill_gpio_probe,
> .remove = rfkill_gpio_remove,
> .driver = {
> .name = "rfkill_gpio",
> .owner = THIS_MODULE,
> + .acpi_match_table = ACPI_PTR(rfkill_acpi_match),
> },
> };
Looks good to me.
Has Mika seen this?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH v2.43 0/5] MPLS actions and matches
From: Ben Pfaff @ 2013-10-16 20:47 UTC (permalink / raw)
To: Jesse Gross
Cc: Simon Horman, dev@openvswitch.org, netdev, Pravin B Shelar,
Ravi K, Isaku Yamahata, Joe Stringer
In-Reply-To: <CAEP_g=-yCas_3MRY0VrP-W6hOi4wRYNW7=8HEB0GYOp--WU60A@mail.gmail.com>
On Wed, Oct 16, 2013 at 01:21:22PM -0700, Jesse Gross wrote:
> On Tue, Oct 15, 2013 at 8:55 PM, Ben Pfaff <blp@nicira.com> wrote:
> > On Thu, Oct 10, 2013 at 09:31:41AM +0900, Simon Horman wrote:
> >> I believe this series addresses the feedback that each of you
> >> gave with regards to recent previous postings of this patch-set.
> >> I'm wondering if you could find some time to review it.
> >
> > I'm waiting for an ack from Jesse, then I'm going to do a final pass and
> > I hope to commit this series at this point. I see some ways that we can
> > improve MPLS support afterward but I don't see any blockers.
>
> I guess that we had a deadlock as I was waiting for you. I though that
> maybe you would commit the rest of the userspace patches and then I
> would just pick up the last two.
Ah, OK.
I will do this, then, after a final pass.
^ permalink raw reply
* Personal Donation Offer
From: frank3 @ 2013-10-16 20:56 UTC (permalink / raw)
To: Recipients
My wife and i adrian won Jackpot Lottery and Decided to donate 2million dollars to you, Contact Mr Adrian on (bayfordga@qq.com) For More Info
^ permalink raw reply
* Re: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
From: Randy Dunlap @ 2013-10-16 21:48 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-next, linux-kernel, Mark Brown, netdev@vger.kernel.org
In-Reply-To: <1381949500-501-1-git-send-email-treding@nvidia.com>
On 10/16/13 11:51, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131016 tag is also provided for convenience.
>
> Gained two new conflicts, but nothing too exciting. x86 and ARM default
> configurations as well as the x86 allmodconfig mostly build fine on the
> final tree. There was a failure for the ARM at91x40_defconfig, but the
> proper fix wasn't immediately obvious to me, so I've left it broken for
> now.
on i386, when CONFIG_NET_NS is not enabled:
net/sched/em_ipset.c: In function 'em_ipset_change':
net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
net/sched/em_ipset.c: In function 'em_ipset_destroy':
net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
--
~Randy
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Hannes Frederic Sowa @ 2013-10-16 21:59 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <alpine.LFD.2.03.1310162252220.1917@ssi.bg>
On Wed, Oct 16, 2013 at 11:22:40PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
>
> > On Wed, Oct 16, 2013 at 10:27:47AM +0300, Julian Anastasov wrote:
> > >
> > > I don't know the IPv6 routing but if we find a way
> > > to keep the desired nexthop in rt6i_gateway and to add
> > > RTF_GATEWAY checks here and there such solution would be more
> > > general. FLOWI_FLAG_KNOWN_NH flag can help, if needed.
> >
> > I thought about this yesterday but did not see an easy way. How does the IPv4
> > implementation accomplish this?
>
> In IPv4 rt->rt_flags has no bit to indicate if the route
> is via gateway (like RTF_GATEWAY in IPv6). We added rt_uses_gateway
> for this purpose.
>
> In the default case, rt_gateway may contain 0 if we return
> cached result, eg. when target is part of a local subnet.
> Then IPVS/TEE/RAW can request valid rt_gateway, even with the price
> of a cloned result, so that rt_gateway can remember the requested
> nexthop which may differ from daddr.
To have ip6_dst_check working, there must to be a valid link from
the rt6_info to the fib6_node. Otherwise we cannot check the serial
number. As I currently see we also need a link from the fib6_node down
to the dst entry for resource management. Thus we would have to insert
the special dst-entry with RTF_GATEWAY and non-null rt6i_gateway back
into the fib and have it globally visible. This could have unforseen
side effects. We still cache all dst entries in the fib. One think I
foresee as a possible problem is the automatic aggregation of ECMP routes,
too.
IPv4 does not seem to need this link at all.
> > ipvs caches the dst in its own infrastructure, so we need to be sure we don't
> > disconnect this dst from the ipv6 routing table, otherwise ip6_dst_check won't
> > recognize when relookups should be done. Playing games with RTF_GATEWAY seems
> > dangerous then.
>
> dst_check works for IPVS. There is a problem only
> with the recent changes that moved the indication for PMTU
> change from dst_check to dst_mtu() calls. But this is safe
> for IPVS, it handles FRAG_NEEDED for the tunneling mode itself.
Ok, I see.
> Initially, I thought IPv6 stores zeroes in rt6i_gateway.
> But now I see rt6_alloc_cow() to be called for the case I assumed
> to fail - when no gateway is used.
>
> So, I'll try to test the IPVS case in the following 1-2 days
> and will report after adding some printks. If xt_TEE has
> the same problem then it should not be IPVS-specific. RAW not
> tested yet.
We should provide something similar to what IPv4 does with the
KNOWN_NH flag. I guess my idea with exchanging rt6i_dst as nexthop would
solve this without too much hassle but this would have to be checked by
implementing it.
I don't think that storing a changed nexthop in the ipv6 cb is that nice and
maintainable.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH v4 net-next] openvswitch: fix vport-netdev unregister
From: Jesse Gross @ 2013-10-16 22:31 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Pravin B Shelar, Jiri Pirko, Cong Wang,
dev@openvswitch.org, netdev
In-Reply-To: <1381874051-4175-1-git-send-email-ast@plumgrid.com>
On Tue, Oct 15, 2013 at 2:54 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
> The combination of two commits:
> commit 8e4e1713e4
> ("openvswitch: Simplify datapath locking.")
> commit 2537b4dd0a
> ("openvswitch:: link upper device for port devices")
>
> introduced a bug where upper_dev wasn't unlinked upon
> netdev_unregister notification
>
> The following steps:
>
> modprobe openvswitch
> ovs-dpctl add-dp test
> ip tuntap add dev tap1 mode tap
> ovs-dpctl add-if test tap1
> ip tuntap del dev tap1 mode tap
>
> are causing multiple warnings:
>
> [ 62.747557] gre: GRE over IPv4 demultiplexor driver
> [ 62.749579] openvswitch: Open vSwitch switching datapath
> [ 62.755087] device test entered promiscuous mode
> [ 62.765911] device tap1 entered promiscuous mode
> [ 62.766033] IPv6: ADDRCONF(NETDEV_UP): tap1: link is not ready
> [ 62.769017] ------------[ cut here ]------------
> [ 62.769022] WARNING: CPU: 1 PID: 3267 at net/core/dev.c:5501 rollback_registered_many+0x20f/0x240()
> [ 62.769023] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769051] CPU: 1 PID: 3267 Comm: ip Not tainted 3.12.0-rc3+ #60
> [ 62.769052] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769053] 0000000000000009 ffff8807f25cbd28 ffffffff8175e575 0000000000000006
> [ 62.769055] 0000000000000000 ffff8807f25cbd68 ffffffff8105314c ffff8807f25cbd58
> [ 62.769057] ffff8807f2634000 ffff8807f25cbdc8 ffff8807f25cbd88 ffff8807f25cbdc8
> [ 62.769059] Call Trace:
> [ 62.769062] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769065] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769067] [<ffffffff8105319a>] warn_slowpath_null+0x1a/0x20
> [ 62.769069] [<ffffffff8162a04f>] rollback_registered_many+0x20f/0x240
> [ 62.769071] [<ffffffff8162a101>] rollback_registered+0x31/0x40
> [ 62.769073] [<ffffffff8162a488>] unregister_netdevice_queue+0x58/0x90
> [ 62.769075] [<ffffffff8154f900>] __tun_detach+0x140/0x340
> [ 62.769077] [<ffffffff8154fb36>] tun_chr_close+0x36/0x60
> [ 62.769080] [<ffffffff811bddaf>] __fput+0xff/0x260
> [ 62.769082] [<ffffffff811bdf5e>] ____fput+0xe/0x10
> [ 62.769084] [<ffffffff8107b515>] task_work_run+0xb5/0xe0
> [ 62.769087] [<ffffffff810029b9>] do_notify_resume+0x59/0x80
> [ 62.769089] [<ffffffff813a41fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 62.769091] [<ffffffff81770f5a>] int_signal+0x12/0x17
> [ 62.769093] ---[ end trace 838756c62e156ffb ]---
> [ 62.769481] ------------[ cut here ]------------
> [ 62.769485] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
> [ 62.769486] sysfs: can not remove 'master', no directory
> [ 62.769486] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769514] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
> [ 62.769515] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769518] Workqueue: events ovs_dp_notify_wq [openvswitch]
> [ 62.769519] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
> [ 62.769521] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b28
> [ 62.769523] 0000000000000000 ffffffff81a87a1f ffff8807f2634000 ffff880037038500
> [ 62.769525] Call Trace:
> [ 62.769528] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769529] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769531] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
> [ 62.769533] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
> [ 62.769535] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
> [ 62.769538] [<ffffffff81631ef7>] __netdev_adjacent_dev_remove+0xf7/0x150
> [ 62.769540] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
> [ 62.769542] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
> [ 62.769544] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
> [ 62.769548] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
> [ 62.769550] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
> [ 62.769552] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
> [ 62.769555] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
> [ 62.769557] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
> [ 62.769559] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
> [ 62.769562] [<ffffffff8107659b>] worker_thread+0x11b/0x370
> [ 62.769564] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
> [ 62.769566] [<ffffffff8107f44a>] kthread+0xea/0xf0
> [ 62.769568] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769570] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
> [ 62.769572] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769573] ---[ end trace 838756c62e156ffc ]---
> [ 62.769574] ------------[ cut here ]------------
> [ 62.769576] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
> [ 62.769577] sysfs: can not remove 'upper_test', no directory
> [ 62.769577] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769603] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
> [ 62.769604] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769606] Workqueue: events ovs_dp_notify_wq [openvswitch]
> [ 62.769607] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
> [ 62.769609] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b58
> [ 62.769611] 0000000000000000 ffff880807ad3bd9 ffff8807f2634000 ffff880037038500
> [ 62.769613] Call Trace:
> [ 62.769615] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769617] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769619] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
> [ 62.769621] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
> [ 62.769622] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
> [ 62.769624] [<ffffffff81631f22>] __netdev_adjacent_dev_remove+0x122/0x150
> [ 62.769627] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
> [ 62.769629] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
> [ 62.769631] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
> [ 62.769633] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
> [ 62.769636] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
> [ 62.769638] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
> [ 62.769640] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
> [ 62.769642] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
> [ 62.769644] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
> [ 62.769646] [<ffffffff8107659b>] worker_thread+0x11b/0x370
> [ 62.769648] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
> [ 62.769650] [<ffffffff8107f44a>] kthread+0xea/0xf0
> [ 62.769652] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769654] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
> [ 62.769656] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769657] ---[ end trace 838756c62e156ffd ]---
> [ 62.769724] device tap1 left promiscuous mode
>
> This patch also affects moving devices between net namespaces.
>
> OVS used to ignore netns move notifications which caused problems.
> Like:
> ovs-dpctl add-if test tap1
> ip link set tap1 netns 3512
> and then removing tap1 inside the namespace will cause hang on missing dev_put.
>
> With this patch OVS will detach dev upon receiving netns move event.
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
From: Stephen Hemminger @ 2013-10-16 22:39 UTC (permalink / raw)
To: Randy Dunlap, Vitaly Lavrov
Cc: Thierry Reding, linux-next, linux-kernel, Mark Brown,
netdev@vger.kernel.org
In-Reply-To: <525F09B0.4080802@infradead.org>
On Wed, 16 Oct 2013 14:48:32 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/16/13 11:51, Thierry Reding wrote:
> > Hi all,
> >
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> > A next-20131016 tag is also provided for convenience.
> >
> > Gained two new conflicts, but nothing too exciting. x86 and ARM default
> > configurations as well as the x86 allmodconfig mostly build fine on the
> > final tree. There was a failure for the ARM at91x40_defconfig, but the
> > proper fix wasn't immediately obvious to me, so I've left it broken for
> > now.
>
> on i386, when CONFIG_NET_NS is not enabled:
>
> net/sched/em_ipset.c: In function 'em_ipset_change':
> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
> net/sched/em_ipset.c: In function 'em_ipset_destroy':
> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
>
>
I think this should fix.
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-16 22:50 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <20131016215953.GD18135@order.stressinduktion.org>
Hello,
On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
> To have ip6_dst_check working, there must to be a valid link from
> the rt6_info to the fib6_node. Otherwise we cannot check the serial
> number. As I currently see we also need a link from the fib6_node down
> to the dst entry for resource management. Thus we would have to insert
> the special dst-entry with RTF_GATEWAY and non-null rt6i_gateway back
> into the fib and have it globally visible. This could have unforseen
> side effects. We still cache all dst entries in the fib. One think I
> foresee as a possible problem is the automatic aggregation of ECMP routes,
> too.
I'm still not sure what is needed. Looking at
ip6_pol_route(), I see that everything should just work: for
routes without RTF_GATEWAY flag we return cloned route
from rt6_alloc_cow() with valid rt6i_gateway. I still
didn't tested the problem myself, so I'll stop with the
comments before that.
> We should provide something similar to what IPv4 does with the
> KNOWN_NH flag. I guess my idea with exchanging rt6i_dst as nexthop would
> solve this without too much hassle but this would have to be checked by
> implementing it.
>
> I don't think that storing a changed nexthop in the ipv6 cb is that nice and
> maintainable.
Agreed. I'm not going to test that change. I'll test
latest net-next without any changes to see where exactly is
the failure because the IPv6 routing seems capable for what
we need. I have problems with my setup, so I'll need some
days. As Simon is also testing the problem, he can find the
reason before me.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ 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