* Re: [net v2 0/3][pull request] Intel Wired LAN Driver Updates 2015-01-06
From: David Miller @ 2015-01-09 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1420594317-6191-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 6 Jan 2015 17:31:54 -0800
> This series contains fixes to i40e only.
>
> Jesse provides a fix for when the driver was polling with interrupts
> disabled the hardware would occasionally not write back descriptors.
> His fix causes the driver to detect this situation and force an interrupt
> to fire which will flush the stuck descriptor.
>
> Anjali provides a couple of fixes, the first corrects an issue where
> the receive port checksum error counter was incrementing incorrectly with
> UDP encapsulated tunneled traffic. The second fix resolves an issue where
> the driver was examining the outer protocol layer to set the inner protocol
> layer checksum offload. In the case of TCP over IPv6 over an IPv4 based
> VXLAN, the inner checksum offloads would be set to look for IPv4/UDP
> instead of IPv6/TCP, so fixed the issue so that the driver will look at
> the proper layer for encapsulation offload settings.
>
> v2: fixed a bug in patch 01 of the series, where the interrupt rate impacted
> 4 port workloads by reducing throughput.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Add support for few debugfs entries
From: David Miller @ 2015-01-09 3:40 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, anish
In-Reply-To: <1420600683-23289-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 7 Jan 2015 08:47:59 +0530
> This patch series adds support for devlog, cim_la, cim_qcfg and mps_tcam
> debugfs entries.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 driver.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net-next] doc: fix the compile error of txtimestamp.c
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:32 -0800
> Vinson reported:
>
> HOSTCC Documentation/networking/timestamping/txtimestamp
> Documentation/networking/timestamping/txtimestamp.c:64:8: error:
> redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:23:0,
> from Documentation/networking/timestamping/txtimestamp.c:33:
> /usr/include/netinet/in.h:456:8: note: originally defined here
> struct in6_pktinfo
> ^
>
> After we sync with libc header, we don't need this ugly hack any more.
>
> Reported-by: Vinson Lee <vlee@twopensource.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next] ipv6: fix redefinition of in6_pktinfo and ip6_mtuinfo
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:31 -0800
> Both netinet/in.h and linux/ipv6.h define these two structs,
> if we include both of them, we got:
>
> /usr/include/linux/ipv6.h:19:8: error: redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:524:8: note: originally defined here
> struct in6_pktinfo
> ^
> In file included from txtimestamp.c:40:0:
> /usr/include/linux/ipv6.h:24:8: error: redefinition of ‘struct ip6_mtuinfo’
> struct ip6_mtuinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:531:8: note: originally defined here
> struct ip6_mtuinfo
> ^
> So similarly to what we did for in6_addr, we need to sync with
> libc header on their definitions.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: David Miller @ 2015-01-09 3:12 UTC (permalink / raw)
To: kernel.org.gnu; +Cc: eric.dumazet, netdev, herbert
In-Reply-To: <CA+U0gVi1cVB4qbXAkPp1LMmNOaDOD2UaAL4riA6O_Q_SnvMQTA@mail.gmail.com>
From: Dennis Chen <kernel.org.gnu@gmail.com>
Date: Fri, 9 Jan 2015 10:26:48 +0800
> I am very curious about the reason that you're removing the atomic ops
> in the stack, what's the benifit?
1) Do not top post.
2) The reason is, obviously, performance.
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 3:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Is this the below patch you mentioned?
https://lkml.org/lkml/2014/7/23/134
--
Den
^ permalink raw reply
* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Ahmed S. Darwish @ 2015-01-09 3:06 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <54AE6FC1.6050007@pengutronix.de>
On Thu, Jan 08, 2015 at 12:53:37PM +0100, Marc Kleine-Budde wrote:
> On 01/05/2015 07:31 PM, Ahmed S. Darwish wrote:
> >
[...]
> >
> > cf->can_id |= CAN_ERR_CRTL;
> > cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
> >
> > stats->rx_over_errors++;
> > stats->rx_errors++;
> >
> > netif_rx(skb);
> >
> > stats->rx_packets++;
> > stats->rx_bytes += cf->can_dlc;
>
> Another patch would be not to touch cf after netif_rx(), please move the stats handling before calling netif_rx(). Same applies to the kvaser_usb_rx_can_msg() function.
>
BTW, is it guaranteed from the SocketCAN stack that netif_rx()
will never return NET_RX_DROPPED? Because if no guarantee
exists, I guess below fragment cannot be completely correct?
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
netif_rx(skb);
On the other hand, I don't see evan a single CAN driver checking
netif_rx() return value, so maybe such a check is an overkill...
Thanks,
Darwish
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
So the only reason for the code '!list_empty()' I can see is to avoid
possible bug code in new drivers, thus pls think if it's possible
that there's a window opened for creating multiple NAPI instances in
the list for the new drivers?
--
Den
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Herbert Xu @ 2015-01-09 2:34 UTC (permalink / raw)
To: Dennis Chen; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <CA+U0gVgS7z601DZvL82EJfYGYb5XQExw9CbnPRpUeN32TWLF7w@mail.gmail.com>
On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>
> Thanks, would you pls give me an example of those drivers? I'll study
> it further...
There are no known drivers doing this currently since that would
be a bug and they would be fixed quickly. But if you look back
in history virtio_net was doing this.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109022752.GA15785@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:27 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:24:18AM +0800, Dennis Chen wrote:
>>
>> Hi Herbert, please see this code piece in napi_poll:
>>
>> /* Some drivers may have called napi_schedule
>> * prior to exhausting their budget.
>> */
>> if (unlikely(!list_empty(&n->poll_list))) {
>> pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
>> n->dev ? n->dev->name : "backlog");
>> goto out_unlock;
>> }
>>
>> Here "Some drivers" may have called napi_schedule to make
>> n->poll_list is not empty, does that mean "Some drivers" will clear
>> NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
>> does that make sense for you question? ;-)
>
> No it tells me that you don't understand the problem at all.
> Those drivers will end up resetting the NAPI_STATE_SCHED bit
> after clearing it.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Thanks, would you pls give me an example of those drivers? I'll study
it further...
--
Den
^ permalink raw reply
* Dear: Account User
From: Helpdesk @ 2015-01-09 2:22 UTC (permalink / raw)
To: netdev
Dear: Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account.
To prevent your email account from been closed, re-validate your mailbox
below please click and visit this site of lick: >>>>
http://survey-upgrade-helpdesk.ezweb123.com/
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2015
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, Herbert Xu, Miller, Eric Dumazet
In-Reply-To: <54AE8048.6040105@cogentembedded.com>
hello,
On Thu, Jan 8, 2015 at 9:04 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 1/8/2015 11:22 AM, Dennis Chen wrote:
>
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>
>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>> ---
>> net/core/dev.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>
>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 683d493..b3107ac 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4619,6 +4619,14 @@ static int napi_poll(struct napi_struct *n,
>> struct list_head *repoll)
>> n->dev ? n->dev->name : "backlog");
>> goto out_unlock;
>> }
>> +
>> + /* Some drivers may exit the polling mode when exhaust the
>
>
> s/exhaust/exhausting/.
>
>> + * budget. Set the NAPI_STATE_SCHED bit to prevent multiple NAPI
>> + * instances in the list in case of next device interrupt raised.
>> + */
>> + if (unlikely(!test_and_set_bit(NAPI_STATE_SCHED, &n->state)))
>> + pr_warn_once("%s: exit polling mode after exhaust the
>> budget\n",
>
>
> Likewise. And s/exit/exiting/.
>
> WBR, Sergei
>
will be updated if applied :-)
--
Den
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Herbert Xu @ 2015-01-09 2:27 UTC (permalink / raw)
To: Dennis Chen; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <CA+U0gVgZr-Mhzest1O_vtCWMwuaQmP30DYb8CLXDG8iTobObYQ@mail.gmail.com>
On Fri, Jan 09, 2015 at 10:24:18AM +0800, Dennis Chen wrote:
>
> Hi Herbert, please see this code piece in napi_poll:
>
> /* Some drivers may have called napi_schedule
> * prior to exhausting their budget.
> */
> if (unlikely(!list_empty(&n->poll_list))) {
> pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
> n->dev ? n->dev->name : "backlog");
> goto out_unlock;
> }
>
> Here "Some drivers" may have called napi_schedule to make
> n->poll_list is not empty, does that mean "Some drivers" will clear
> NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
> does that make sense for you question? ;-)
No it tells me that you don't understand the problem at all.
Those drivers will end up resetting the NAPI_STATE_SCHED bit
after clearing it.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Herbert Xu, Miller
In-Reply-To: <1420728671.5947.47.camel@edumazet-glaptop2.roam.corp.google.com>
I am very curious about the reason that you're removing the atomic ops
in the stack, what's the benifit?
On Thu, Jan 8, 2015 at 10:51 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2015-01-08 at 16:22 +0800, Dennis Chen wrote:
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>> ---
>
>
> Well no.
>
> I am removing some atomic ops in the stack, please do not add new ones,
> especially if no driver is that buggy.
>
> The unlikely() wont help the expensive stuff being done here.
>
>
--
Den
^ permalink raw reply
* [PATCH net-next v2 2/2 RESEND] r8152: check the status before submitting rx
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-114-Taiwan-albertk@realtek.com>
Don't submit the rx if the device is unplugged, stopped, or
linking down.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cd93388..b23426e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
int ret;
+ /* The rx would be stopped, so skip submitting */
+ if (test_bit(RTL8152_UNPLUG, &tp->flags) ||
+ !test_bit(WORK_ENABLE, &tp->flags) || !netif_carrier_ok(tp->netdev))
+ return 0;
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
agg->head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 1/2 RESEND] r8152: call rtl_start_rx after netif_carrier_on
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-114-Taiwan-albertk@realtek.com>
Remove rtl_start_rx() from rtl_enable() and put it after calling
netif_carrier_on().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 57ec23e..cd93388 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2059,7 +2059,7 @@ static int rtl_enable(struct r8152 *tp)
rxdy_gated_en(tp, false);
- return rtl_start_rx(tp);
+ return 0;
}
static int rtl8152_enable(struct r8152 *tp)
@@ -2874,6 +2874,7 @@ static void set_carrier(struct r8152 *tp)
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_carrier_on(netdev);
+ rtl_start_rx(tp);
}
} else {
if (tp->speed & LINK_STATUS) {
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 0/2 RESEND] r8152: adjust r8152_submit_rx
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
v2:
Replace the patch #1 with "call rtl_start_rx after netif_carrier_on".
For patch #2, replace checking tp->speed with netif_carrier_ok.
v1:
Avoid r8152_submit_rx() from submitting rx during unexpected
moment. This could reduce the time of stopping rx.
For patch #1, the tp->speed should be updated early. Then,
the patch #2 could use it to check the current linking status.
Hayes Wang (2):
r8152: call rtl_start_rx after netif_carrier_on
r8152: check the status before submitting rx
drivers/net/usb/r8152.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <20150108111554.GA8720@gondor.apana.org.au>
On Thu, Jan 8, 2015 at 7:15 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Dennis Chen <kernel.org.gnu@gmail.com> wrote:
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>
> Which driver is doing this?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert, please see this code piece in napi_poll:
/* Some drivers may have called napi_schedule
* prior to exhausting their budget.
*/
if (unlikely(!list_empty(&n->poll_list))) {
pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
n->dev ? n->dev->name : "backlog");
goto out_unlock;
}
Here "Some drivers" may have called napi_schedule to make
n->poll_list is not empty, does that mean "Some drivers" will clear
NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
does that make sense for you question? ;-)
--
Den
^ permalink raw reply
* Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn_add()
From: Scott Feldman @ 2015-01-09 1:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Siva Mannem, Netdev
In-Reply-To: <20150107125301.GE1888@nanopsycho.orion>
On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@gmail.com wrote:
>>Hi,
>>
>>I am trying to understand the ongoing switch device offload effort and
>>am following the discussions. I have a question regarding
>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>enabled on a port that is attached to a bridge that has vlan filtering
>>enabled.
>>
>>If I understand correctly, when IFLA_BRPORT_LEARNING_SYNC is set on a
>>bridge port, fdb entries that are learnt externally(may be learnt by
>>hardware and driver is notified) are synced to bridges fdb using
>>br_fdb_external_learn_add(). The fdb
>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>this method are also deleted by the aging logic after the aging time
>>even though L2 data forwadring happens in hardware.
This is correct...
>> Is there a way
>>where aging can be disabled for these entries? and let the entries be
>>removed only via br_fdb_external_learn_delete()? or am I missing
>>something?
>
> Currently extenaly learned fdb entries are indeed removed during aging
> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
> and not remove that fdbs. What do you think Scott?
Something like that would work, if we added another brport flag to
control that. With the current arrangement, using bridge for aging
out entries, we want br_fdb_cleanup removing the external_learned
fdbs, but if there was another brport flag we could fine tune that.
Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that. I'm
not sure how aging settings for the bridge are pushed down to offload
hw, or if there is a different set for hw.
But, isn't it nice to let Linux bridge control aging? That way,
bridge -s fdb dump shows nice statistics on fdb entries. Hardware
isn't involved in the aging processes (other than being told to remove
an entry). Simple hardware equals simple driver. Linux remains
control point.
-scott
^ permalink raw reply
* Re: [PATCH next] net: e1000e: support txtd update delay via xmit_more
From: Jeff Kirsher @ 2015-01-09 1:22 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <1420624162-24206-1-git-send-email-fw@strlen.de>
On Wed, Jan 7, 2015 at 1:49 AM, Florian Westphal <fw@strlen.de> wrote:
> Don't update tx tail descriptor if queue hasn't been stopped
> and we know at least one more skb will be sent right away.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
Thanks Florian, I will add your patch to my queue.
^ permalink raw reply
* Re: [PATCH net-next] mac80211: silent build warnings
From: Ying Xue @ 2015-01-09 1:00 UTC (permalink / raw)
To: Sergei Shtylyov, johannes; +Cc: netdev, linux-wireless
In-Reply-To: <54AE7F3F.3070802@cogentembedded.com>
On 01/08/2015 08:59 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 1/8/2015 10:04 AM, Ying Xue wrote:
>
>> Silent the following build warnings:
>
>> net/mac80211/mlme.c: In function ‘ieee80211_rx_mgmt_beacon’:
>> net/mac80211/mlme.c:1348:3: warning: ‘pwr_level_cisco’ may be used
>> uninitialized in this function [-Wuninitialized]
>> net/mac80211/mlme.c:1315:6: note: ‘pwr_level_cisco’ was declared here
>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>> ---
>> net/mac80211/mlme.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 2c36c47..13b5506 100644
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -1312,7 +1312,7 @@ static u32 ieee80211_handle_pwr_constr(struct
>> ieee80211_sub_if_data *sdata,
>> {
>> bool has_80211h_pwr = false, has_cisco_pwr = false;
>> int chan_pwr = 0, pwr_reduction_80211h = 0;
>> - int pwr_level_cisco, pwr_level_80211h;
>> + int pwr_level_cisco = 0, pwr_level_80211h = 0;
>
> OK, but why are you also initializing the second variable?
>
Although the second variable is not warned in above compile warning
message, but it should be if we take a look at the code associated with it.
However, as Johannes confirmed, the first change is unnecessary at all.
So please ignore the patch.
Thanks,
Ying
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Pablo Neira Ayuso @ 2015-01-09 0:05 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <1420756756.1755002.211556745.0418D128@webmail.messagingengine.com>
On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> Hi Pablo,
>
> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > ipv6_find_hdr() function is designed to return the transport protocol.
> > After the proposed change, it will return extension header numbers.
> > This will break existing ip6tables rulesets since the `-p' option
> > relies on this function to match the transport protocol.
> >
> > Note that the AH header is skipped (see code a bit below this
> > problematic fragmentation handling) so the follow up header after the
> > AH header is returned as the transport header.
> >
> > We can probably return the AH protocol number for non-1st fragments.
> > However, that would be something new to ip6tables since nobody has
> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > the user to allow this, but we would accept all kind of fragmented AH
> > traffic through the firewall since we cannot know what transport
> > protocol contains from non-1st fragments (unless I'm missing anything,
> > I need to have a closer look at this again tomorrow with fresher
> > mind).
>
> The code in question is guarded by (_frag_off != 0), so we are
> definitely processing a non-1st fragment currently. The -p match would
> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> will find the real transport (final) header at this point (I hope I
> followed the code correctly here).
Then, Rahul should get things working by modprobing nf_defrag_ipv6.
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Francois Romieu @ 2015-01-09 0:00 UTC (permalink / raw)
To: Stephen Wang
Cc: jcliburn-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420754626-30121-1-git-send-email-wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Stephen Wang <wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> :
> This driver adds support for the internal GMACs on IPQ806x SoCs.
> It supports the device-tree and will register up to 4 ethernet
> interfaces.
>
> Signed-off-by: Stephen Wang <wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
[...]
> +/*
> + * NSS GMAC data plane ops, default would be slowpath and can be override by
> + * nss-drv
> + */
> +struct nss_gmac_data_plane_ops {
> + int (*open)(void *ctx, uint32_t tx_desc_ring, uint32_t rx_desc_ring,
> + uint32_t mode);
> + int (*close)(void *ctx);
> + int (*link_state)(void *ctx, uint32_t link_state);
> + int (*mac_addr)(void *ctx, uint8_t *addr);
> + int (*change_mtu)(void *ctx, uint32_t mtu);
> + int (*xmit)(void *ctx, struct sk_buff *os_buf);
> +};
Weak types.
[...]
> +/*
> + * nss_gmac_register_offload()
> + *
> + * @param[netdev] netdev instance that is going to register
> + * @param[dp_ops] dataplan ops for chaning mac addr/mtu/link status
> + * @param[ctx] passing the ctx of this nss_phy_if to gmac
> + *
> + * @return Return SUCCESS or FAILURE
> + */
> +int nss_gmac_override_data_plane(struct net_device *netdev,
> + struct nss_gmac_data_plane_ops *dp_ops,
> + void *ctx)
> +{
> + struct nss_gmac_dev *gmacdev = (struct nss_gmac_dev *)netdev_priv(netdev);
> +
> + BUG_ON(!gmacdev);
> +
> + if (!dp_ops->open || !dp_ops->close || !dp_ops->link_state
> + || !dp_ops->mac_addr || !dp_ops->change_mtu || !dp_ops->xmit) {
> + netdev_dbg(netdev, "%s: All the op functions must be present, reject this registeration",
> + __func__);
> + return NSS_GMAC_FAILURE;
> + }
> +
> + /*
> + * If this gmac is up, close the netdev to force TX/RX stop
> + */
> + if (test_bit(__NSS_GMAC_UP, &gmacdev->flags))
> + nss_gmac_linux_close(netdev);
> +
> + /* Recored the data_plane_ctx, data_plane_ops */
> + gmacdev->data_plane_ctx = ctx;
> + gmacdev->data_plane_ops = dp_ops;
> + gmacdev->first_linkup_done = 0;
> +
> + return NSS_GMAC_SUCCESS;
> +}
> +EXPORT_SYMBOL(nss_gmac_override_data_plane);
Why is this hook needed ?
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Arnd Bergmann @ 2015-01-08 23:35 UTC (permalink / raw)
To: Stephen Wang
Cc: jcliburn, grant.likely, robh+dt, linux-kernel, netdev, devicetree
In-Reply-To: <1420754626-30121-1-git-send-email-wstephen@codeaurora.org>
On Thursday 08 January 2015 14:03:46 Stephen Wang wrote:
> This driver adds support for the internal GMACs on IPQ806x SoCs.
> It supports the device-tree and will register up to 4 ethernet
> interfaces.
>
> Signed-off-by: Stephen Wang <wstephen@codeaurora.org>
Just a very brief review here. The driver is far too long to be
reviewed in one piece, and hopefully is not needed at all if my
suspicion is correct that we already have a driver for the
hardware.
> diff --git a/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
> new file mode 100644
> index 0000000..806f2e6
> --- /dev/null
> +++ b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
> @@ -0,0 +1,14 @@
> +Linux Driver for 3504 DWC Ether MAC 10/100/1000 Universal
> +Linux Driver for 3507 DWC Ether MAC 10/100 Universal
> +
> +IMPORTANT: Synopsys Ethernet MAC Linux Software Drivers and documentation (hereinafter, "Software") are unsupported proprietary works of Synopsys, Inc. unless otherwise expressly agreed to in writing between Synopsys and you.
> +
> +The Software uses certain Linux kernel functionality and may therefore be subject to the GNU Public License which is available at:
> +http://www.gnu.org/licenses/gpl.html
It sounds like this one is related to the dwmac driver in
drivers/net/ethernet/stmicro/stmmac/. Please move the code into
the same directory and reuse as much as you can.
If this is a completely unrelated part, it should probably go
into drivers/net/ethernet/designware or drivers/net/ethernet/synopsys.
> +#ifdef CONFIG_OF
> +#include <msm_nss_gmac.h>
> +#else
> +#include <mach/msm_nss_gmac.h>
> +#endif
Drop the non-CONFIG_OF part here and elsewhere, we don't support
separate platform directories any more, and mach-qcom is already
DT-only.
> +/**********************************************************
> + * GMAC registers Map
> + * For Pci based system address is BARx + gmac_register_base
> + * For any other system translation is done accordingly
> + **********************************************************/
> +enum gmac_registers {
> + gmac_config = 0x0000, /* Mac config Register */
> + gmac_frame_filter = 0x0004, /* Mac frame filtering controls */
> + gmac_hash_high = 0x0008, /* Multi-cast hash table high */
> + gmac_hash_low = 0x000c, /* Multi-cast hash table low */
> + gmac_gmii_addr = 0x0010, /* GMII address Register(ext. Phy) */
> + gmac_gmii_data = 0x0014, /* GMII data Register(ext. Phy) */
> + gmac_flow_control = 0x0018, /* Flow control Register */
> + gmac_vlan = 0x001c, /* VLAN tag Register (IEEE 802.1Q) */
> + gmac_version = 0x0020, /* GMAC Core Version Register */
> + gmac_wakeup_addr = 0x0028, /* GMAC wake-up frame filter adrress
> + reg */
This looks a lot like dwmac1000 as well.
> + if (of_property_read_u32(np, "qcom,id", &gmacdev->macid)
> + || of_property_read_u32(np, "qcom,emulation", &gmaccfg->emulation)
> + || of_property_read_u32(np, "qcom,phy_mii_type", &gmaccfg->phy_mii_type)
> + || of_property_read_u32(np, "qcom,phy_mdio_addr", &gmaccfg->phy_mdio_addr)
> + || of_property_read_u32(np, "qcom,rgmii_delay", &gmaccfg->rgmii_delay)
> + || of_property_read_u32(np, "qcom,poll_required", &gmaccfg->poll_required)
> + || of_property_read_u32(np, "qcom,forced_speed", &gmaccfg->forced_speed)
> + || of_property_read_u32(np, "qcom,forced_duplex", &gmaccfg->forced_duplex)
> + || of_property_read_u32(np, "qcom,irq", &netdev->irq)
> + || of_property_read_u32(np, "qcom,socver", &gmaccfg->socver)) {
This is not an acceptable way to pass data from DT, please use the standard properties.
> + if (test_bit(__NSS_GMAC_LINKPOLL, &gmacdev->flags)) {
> +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(3, 8, 0))
> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
> + &nss_gmac_adjust_link, 0, phyif);
> +#else
> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
> + &nss_gmac_adjust_link, phyif);
> +#endif
Drop all LINUX_VERSION_CODE checks
> + if (IS_ERR_OR_NULL(gmacdev->phydev)) {
> + netdev_dbg(netdev, "PHY %s attach FAIL", phy_id);
> + ret = -EIO;
> + goto nss_gmac_phy_attach_fail;
> + }
Also any IS_ERR_OR_NULL checks, you are using the API incorrectly.
> +static struct of_device_id nss_gmac_dt_ids[] = {
> + { .compatible = "qcom,nss-gmac0" },
> + { .compatible = "qcom,nss-gmac1" },
> + { .compatible = "qcom,nss-gmac2" },
> + { .compatible = "qcom,nss-gmac3" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, nss_gmac_dt_ids);
Are all four versions supported by this driver?
Each one of these needs its own devicetree binding that documents which
hardware it is for and what the supported DT properties are.
> +static struct platform_driver nss_gmac_drv = {
> + .probe = nss_gmac_probe,
> + .remove = nss_gmac_remove,
> + .driver = {
> + .name = "nss-gmac",
> + .owner = THIS_MODULE,
> +#ifdef CONFIG_OF
> + .of_match_table = of_match_ptr(nss_gmac_dt_ids),
> +#endif
The redundancy here is redundant and unnecessary.
> +
> +/**
> + * @brief IOCTL interface.
> + * This function is mainly for debugging purpose.
> + * This provides hooks for Register read write, Retrieve descriptor status
> + * and Retreiving Device structure information.
> + * @param[in] pointer to net_device structure.
> + * @param[in] pointer to ifreq structure.
> + * @param[in] ioctl command.
> + * @return Returns 0 on success Error code on failure.
> + */
> +static int32_t nss_gmac_linux_do_ioctl(struct net_device *netdev,
> + struct ifreq *ifr, int32_t cmd)
> +{
Remove the private ioctls.
> +/**
> + * @brief Stats Callback to receive statistics from NSS
> + * @param[in] pointer to gmac context
> + * @param[in] pointer to gmac statistics
> + * @return Returns void.
> + */
> +static void nss_gmac_stats_receive(struct nss_gmac_dev *gmacdev,
> + struct nss_gmac_stats *gstat)
> +{
...
> +}
> +EXPORT_SYMBOL(nss_gmac_receive);
Why multiple modules instead of linking everything together?
> +
> +/**
> + * NSS Driver interface APIs
> + */
What is an NSS driver?
> +/*
> + * nss_gmac_open_work()
> + * Schedule delayed work to open the netdev again
> + */
> +void nss_gmac_open_work(struct work_struct *work)
> +{
> + struct nss_gmac_dev *gmacdev = container_of(to_delayed_work(work),
> + struct nss_gmac_dev, gmacwork);
> +
> + netdev_dbg(gmacdev->netdev, "Do the network up in delayed queue %s\n",
> + gmacdev->netdev->name);
> + nss_gmac_linux_open(gmacdev->netdev);
> +}
You seem to have an operating system abstraction layer in here. We know
which OS we are running on, so please remove the abstraction.
Arnd
^ permalink raw reply
* [PATCH iproute2 -next v3] ip: route: add congestion control metric
From: Daniel Borkmann @ 2015-01-08 23:13 UTC (permalink / raw)
To: stephen; +Cc: fw, netdev
This patch adds configuration and dumping of congestion control metric
for ip route, for example:
ip route add <dst> dev foo congctl [lock] dctcp
Reference: http://thread.gmane.org/gmane.linux.network/344733
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
v2->v3:
- use rta_getattr_u32 et al helpers
- regarding discussed mx(un)lock, I'll do a follow-up for
all users inside iproute_modify() if that is wished
v1->v2:
- adapted mxlock setting to kernel style
- use arg directly in rta_addattr_l
include/linux/rtnetlink.h | 2 ++
ip/iproute.c | 22 ++++++++++++++++++----
man/man8/ip-route.8.in | 19 ++++++++++++++++++-
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 9aa5c2f..ac4af97 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -389,6 +389,8 @@ enum {
#define RTAX_INITRWND RTAX_INITRWND
RTAX_QUICKACK,
#define RTAX_QUICKACK RTAX_QUICKACK
+ RTAX_CC_ALGO,
+#define RTAX_CC_ALGO RTAX_CC_ALGO
__RTAX_MAX
};
diff --git a/ip/iproute.c b/ip/iproute.c
index 5a496a9..76d8e36 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -53,6 +53,7 @@ static const char *mx_names[RTAX_MAX+1] = {
[RTAX_RTO_MIN] = "rto_min",
[RTAX_INITRWND] = "initrwnd",
[RTAX_QUICKACK] = "quickack",
+ [RTAX_CC_ALGO] = "congctl",
};
static void usage(void) __attribute__((noreturn));
@@ -80,8 +81,7 @@ static void usage(void)
fprintf(stderr, " [ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ]\n");
fprintf(stderr, " [ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ]\n");
fprintf(stderr, " [ rto_min TIME ] [ hoplimit NUMBER ] [ initrwnd NUMBER ]\n");
- fprintf(stderr, " [ features FEATURES ]\n");
- fprintf(stderr, " [ quickack BOOL ]\n");
+ fprintf(stderr, " [ features FEATURES ] [ quickack BOOL ] [ congctl NAME ]\n");
fprintf(stderr, "TYPE := [ unicast | local | broadcast | multicast | throw |\n");
fprintf(stderr, " unreachable | prohibit | blackhole | nat ]\n");
fprintf(stderr, "TABLE_ID := [ local | main | default | all | NUMBER ]\n");
@@ -536,7 +536,7 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
mxlock = *(unsigned*)RTA_DATA(mxrta[RTAX_LOCK]);
for (i=2; i<= RTAX_MAX; i++) {
- unsigned val;
+ __u32 val;
if (mxrta[i] == NULL)
continue;
@@ -545,10 +545,12 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, " %s", mx_names[i]);
else
fprintf(fp, " metric %d", i);
+
if (mxlock & (1<<i))
fprintf(fp, " lock");
+ if (i != RTAX_CC_ALGO)
+ val = rta_getattr_u32(mxrta[i]);
- val = *(unsigned*)RTA_DATA(mxrta[i]);
switch (i) {
case RTAX_FEATURES:
print_rtax_features(fp, val);
@@ -573,6 +575,10 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, " %gs", val/1e3);
else
fprintf(fp, " %ums", val);
+ break;
+ case RTAX_CC_ALGO:
+ fprintf(fp, " %s", rta_getattr_str(mxrta[i]));
+ break;
}
}
}
@@ -925,6 +931,14 @@ static int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
if (quickack != 1 && quickack != 0)
invarg("\"quickack\" value should be 0 or 1\n", *argv);
rta_addattr32(mxrta, sizeof(mxbuf), RTAX_QUICKACK, quickack);
+ } else if (matches(*argv, "congctl") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "lock") == 0) {
+ mxlock |= 1 << RTAX_CC_ALGO;
+ NEXT_ARG();
+ }
+ rta_addattr_l(mxrta, sizeof(mxbuf), RTAX_CC_ALGO, *argv,
+ strlen(*argv));
} else if (matches(*argv, "rttvar") == 0) {
unsigned win;
NEXT_ARG();
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 89960c1..2b1583d 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -116,7 +116,9 @@ replace " } "
.B features
.IR FEATURES " ] [ "
.B quickack
-.IR BOOL " ]"
+.IR BOOL " ] [ "
+.B congctl
+.IR NAME " ]"
.ti -8
.IR TYPE " := [ "
@@ -433,6 +435,21 @@ sysctl is set to 0.
Enable or disable quick ack for connections to this destination.
.TP
+.BI congctl " NAME " "(3.20+ only)"
+.TP
+.BI "congctl lock" " NAME " "(3.20+ only)"
+Sets a specific TCP congestion control algorithm only for a given destination.
+If not specified, Linux keeps the current global default TCP congestion control
+algorithm, or the one set from the application. If the modifier
+.B lock
+is not used, an application may nevertheless overwrite the suggested congestion
+control algorithm for that destination. If the modifier
+.B lock
+is used, then an application is not allowed to overwrite the specified congestion
+control algorithm for that destination, thus it will be enforced/guaranteed to
+use the proposed algorithm.
+
+.TP
.BI advmss " NUMBER " "(2.3.15+ only)"
the MSS ('Maximal Segment Size') to advertise to these
destinations when establishing TCP connections. If it is not given,
--
1.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox