* [next-queue v2 0/4] ixgbe: Enable tso and checksum offload with ipsec
From: Shannon Nelson @ 2018-03-16 18:09 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, steffen.klassert
This patchset fixes up the bits for supporting TSO and checksum
offload in conjunction with IPsec offload. This brings the
throughput of a simple iperf test back up to nearly line rate.
v2: fixes in patch 4 from Alex's comments
Shannon Nelson (4):
ixgbe: no need for ipsec csum feature check
ixgbe: remove unneeded ipsec test in Tx path
ixgbe: no need for esp trailer if gso
ixgbe: enable tso with ipsec offload
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 45 +++++++++++++++-----------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 30 ++++++++---------
2 files changed, 42 insertions(+), 33 deletions(-)
--
2.7.4
^ permalink raw reply
* [next-queue v2 3/4] ixgbe: no need for esp trailer if gso
From: Shannon Nelson @ 2018-03-16 18:09 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, steffen.klassert
In-Reply-To: <1521223747-12018-1-git-send-email-shannon.nelson@oracle.com>
There is no need to calculate the trailer length if we're doing
a GSO/TSO, as there is no trailer added to the packet data.
Also, don't bother clearing the flags field as it was already
cleared earlier.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 37 +++++++++++++++-----------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index f225452..5ddea43 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -774,11 +774,7 @@ int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring,
first->tx_flags |= IXGBE_TX_FLAGS_IPSEC | IXGBE_TX_FLAGS_CC;
- itd->flags = 0;
if (xs->id.proto == IPPROTO_ESP) {
- struct sk_buff *skb = first->skb;
- int ret, authlen, trailerlen;
- u8 padlen;
itd->flags |= IXGBE_ADVTXD_TUCMD_IPSEC_TYPE_ESP |
IXGBE_ADVTXD_TUCMD_L4T_TCP;
@@ -790,19 +786,28 @@ int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring,
* padlen bytes of padding. This ends up not the same
* as the static value found in xs->props.trailer_len (21).
*
- * The "correct" way to get the auth length would be to use
- * authlen = crypto_aead_authsize(xs->data);
- * but since we know we only have one size to worry about
- * we can let the compiler use the constant and save us a
- * few CPU cycles.
+ * ... but if we're doing GSO, don't bother as the stack
+ * doesn't add a trailer for those.
*/
- authlen = IXGBE_IPSEC_AUTH_BITS / 8;
-
- ret = skb_copy_bits(skb, skb->len - (authlen + 2), &padlen, 1);
- if (unlikely(ret))
- return 0;
- trailerlen = authlen + 2 + padlen;
- itd->trailer_len = trailerlen;
+ if (!skb_is_gso(first->skb)) {
+ /* The "correct" way to get the auth length would be
+ * to use
+ * authlen = crypto_aead_authsize(xs->data);
+ * but since we know we only have one size to worry
+ * about * we can let the compiler use the constant
+ * and save us a few CPU cycles.
+ */
+ const int authlen = IXGBE_IPSEC_AUTH_BITS / 8;
+ struct sk_buff *skb = first->skb;
+ u8 padlen;
+ int ret;
+
+ ret = skb_copy_bits(skb, skb->len - (authlen + 2),
+ &padlen, 1);
+ if (unlikely(ret))
+ return 0;
+ itd->trailer_len = authlen + 2 + padlen;
+ }
}
if (tsa->encrypt)
itd->flags |= IXGBE_ADVTXD_TUCMD_IPSEC_ENCRYPT_EN;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Kirill Tkhai @ 2018-03-16 18:14 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: santosh.shilimkar, davem, netdev, linux-rdma, rds-devel, edumazet
In-Reply-To: <20180316172918.GM16870@oracle.com>
On 16.03.2018 20:29, Sowmini Varadhan wrote:
>
> I had taken some of this offline, but it occurs to me
> that some of these notes should be saved to the netdev archives,
> in case this question pops up again in a few years.
>
> When I run your patch, I get a repeatable panic by doing
> modprobe rds-tcp
> ip netns create blue
> the panic is because we are finding a null trn in rds_tcp_init_net.
I did the second version and sent you. Have you tried it?
> I think there's something very disturbed about calling
> register_pernet_operations() twice, once via
> register_pernet_device() and again via register_pernet_subsys().
Calling netdevice handler for every event is more disturbing,
as number of events is several times bigger, than one more
pernet exit method.
> I suspect this has everything to do with the panic but I have
> not had time to debug every little detail here.
You speak in the way I forced you to spend a lot of time debugging
my patches. But I sent you only one with a warn it's not tested.
(but twice -- since the second time I used --patience diff option
to make idea more visible for you). It's strange to hear this from
you.
> In general, rds_tcp is not a network device, it is a kernel
> module. That is the fundamental problem here.
>
> To repeat the comments form net_namespace.h:
> * Network interfaces need to be removed from a dying netns _before_
> * subsys notifiers can be called, as most of the network code cleanup
> * (which is done from subsys notifiers) runs with the assumption that
> * dev_remove_pack has been called so no new packets will arrive during
> * and after the cleanup functions have been called. dev_remove_pack
> * is not per namespace so instead the guarantee of no more packets
> * arriving in a network namespace is provided by ensuring that all
> * network devices and all sockets have left the network namespace
> * before the cleanup methods are called.
>
> when the "blue" netns starts up, it creates at least one kernel listen
> socket on *.16385. This socket, and any other child/client sockets
> created must be cleaned up before the cleanup_net can happen.
>
> This is why I chose to call regster_pernet_subsys. Again, as per
> comments in net_namespace.h:
>
> * Use these carefully. If you implement a network device and it
> * needs per network namespace operations use device pernet operations,
> * otherwise use pernet subsys operations.
This is not a strict rule, and currently I'm working on pernet_operations
synchronization. This commentary is for generic code, while your rds
is differ from the rest of ordinary pernet_operations.
> On (03/16/18 18:51), Kirill Tkhai wrote:
>>> Let's find another approach. Could you tell what problem we have in
>>> case of rds_tcp_dev_ops is declared as pernet_device?
>
> As above, rds-tcp is not a network device.
It's not an agrument. It's not a rule, what you read in the comment.
We need to use rules of reasonableness, and the generic rules do not
fit to your driver. So, it's need to search a solution. Be the only
user NETDEV_UNREGISTER_FINAL in the kernel does not look a good one.
>> One more question. Which time we take a reference of loopback device?
>> Is it possible before we created a net completely?
>
> We dont take a reference on the loopback device.
> We make sure none of the kernel sockets does a get_net() so
> that we dont block the cleanup_net, and then, when all
> the network interfaces have been taken down (loopback is
> the last one) we know there are no more packets coming in
> and out, so it is safe to dismantle all kernel sockets
> created by rds-tcp.
So that, if RDS packets does not act on netdev refcount,
which circular dependence did you mean in your second
message (quote below)?
>As I recall, when I wrote the initial patchset, my problem
>was that in order to let the module unload make progress,
>all these sockets had to be cleaned up. But to clean up these
>sockets, net_device cleanup had to complete (should not have
>any new incoming connections to the listen endpoint on a
>non-loopback socket) so I ended up with a circular dependancy.
Kirill
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-03-16 18:14 UTC (permalink / raw)
To: Alexander Duyck, Gomes, Vinicius
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Sanchez-Palencia, Jesus
In-Reply-To: <CAKgT0UchtULE4YT30JQbORS6O=g20cjkmodX7UHkn6E-N9jxrA@mail.gmail.com>
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Friday, March 16, 2018 11:07 AM
> To: Gomes, Vinicius <vinicius.gomes@intel.com>
> Cc: Brown, Aaron F <aaron.f.brown@intel.com>; intel-wired-
> lan@lists.osuosl.org; netdev@vger.kernel.org; Sanchez-Palencia, Jesus
> <jesus.sanchez-palencia@intel.com>
> Subject: Re: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address support for ethtool nftuple filters
>
> On Fri, Mar 16, 2018 at 10:59 AM, Vinicius Costa Gomes
> <vinicius.gomes@intel.com> wrote:
> > Hi,
> >
> > Alexander Duyck <alexander.duyck@gmail.com> writes:
> >
> >> On Tue, Mar 13, 2018 at 8:04 PM, Brown, Aaron F
> <aaron.f.brown@intel.com> wrote:
> >>>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> >>>> Behalf Of Vinicius Costa Gomes
> >>>> Sent: Wednesday, March 7, 2018 4:37 PM
> >>>> To: intel-wired-lan@lists.osuosl.org
> >>>> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> >>>> palencia@intel.com>
> >>>> Subject: [Intel-wired-lan] [next-queue PATCH v4 6/8] igb: Add MAC
> address
> >>>> support for ethtool nftuple filters
> >>>>
> >>>> This adds the capability of configuring the queue steering of arriving
> >>>> packets based on their source and destination MAC addresses.
> >>>>
> >>>> In practical terms this adds support for the following use cases,
> >>>> characterized by these examples:
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> >>>> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> >>>> to the RX queue 0)
> >>>>
> >>>> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> >>>> (this will direct packets with source address "44:44:44:44:44:44" to
> >>>> the RX queue 3)
> >>>
> >>> This seems to work fine on i210, and the patch series allows me to set
> the rx filters on the i350, i354 and i211, but it is not directing the packets to
> the queue I request.
> >>>
> >>> With the exception of i210 the rx_queues number does not seem to be
> effected by setting the filter. In the case of i211 the rx packets stay on
> rx_queue 0 with or without an ether src or dst filter. The first example one
> seems to work at first since it's directing to queue 0, but changing the filter to
> "action 1" does not change the behavior. With the i350 and i354 ports the
> packets are spread across the rx_queues with or without the filter set.
> >>
> >> Do any of the other parts actually support this functionality? I don't
> >> think they do.
> >
> > From what I can see, the only other part that supports queue steering (by
> MAC
> > addresses) is the 82575. But as I don't have any of those handy, making
> > it work only for the i210 seems more reasonable, to avoid getting into
> > this situation again.
>
> That sounds good to me. What you might do is add a comment explaining
> that this is only supported on 82575 and i210 wherever you put the
> check that limits this. Then if we have time for the
> development/validation efforts, or someone in the community does they
> could take it upon themselves to enable and test it for 82575.
>
> I have done similar things in the past. As long as it is clear that
> the reason why we limited it to i210 is mostly because of
> development/validation resources somebody else can come along and
> enable it if they have the resources and time to invest in doing so.
I do have a few of 82575 NICs in my lab and am perfectly willing to test them on whatever you come up with. But I don't believe it is a common part at all so have no qualms with limiting it to i210.
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Al Viro @ 2018-03-16 18:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Florian Weimer, Kees Cook, Andrew Morton, Josh Poimboeuf,
Rasmus Villemoes, Randy Dunlap, Miguel Ojeda, Ingo Molnar,
David Laight, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <20180316175502.GE30522@ZenIV.linux.org.uk>
On Fri, Mar 16, 2018 at 05:55:02PM +0000, Al Viro wrote:
> On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote:
> > t.c: In function ‘test’:
> > t.c:6:6: error: argument to variable-length array is too large
> > [-Werror=vla-larger-than=]
> > int array[(1,100)];
> >
> > Gcc people are crazy.
>
> That's not them, that's C standard regarding ICE. 1,100 is *not* a
> constant expression as far as the standard is concerned, and that
> type is actually a VLA with the size that can be optimized into
> a compiler-calculated value.
>
> Would you argue that in
s/argue/agree/, sorry
> void foo(char c)
> {
> int a[(c<<1) + 10 - c + 2 - c];
>
> a is not a VLA?
FWIW, 6.6 starts with
constant-expression:
conditional-expression
for syntax, with 6.6p3 being "Constant expression shall not contain
assignment, increment, decrement, function call or comma operators,
except when they are contained in a subexpression that is not evaluated",
with "The operand of sizeof operator is usually not evaluated (6.5.3.4)"
as a footnote.
6.6p10 allows implementation to accept other forms of constant expressions,
but arguing that such-and-such construct surely must be recognized as one,
when there are perfectly portable ways to achieve the same...
Realistically, code like that can come only from macros, and one can wrap
the damn thing into 0 * sizeof(..., 0) + just fine there. Which will
satisfy the conditions for sizeof argument not being evaluated...
^ permalink raw reply
* Re: [PATCH net-next v3 1/7] ibmvnic: Generalize TX pool structure
From: Thomas Falcon @ 2018-03-16 18:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jallen, nfont
In-Reply-To: <20180316.125202.392278218093047323.davem@davemloft.net>
On 03/16/2018 11:52 AM, David Miller wrote:
> From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> Date: Thu, 15 Mar 2018 11:02:37 -0500
>
>> Remove some unused fields in the structure and include values
>> describing the individual buffer size and number of buffers in
>> a TX pool. This allows us to use these fields for TX pool buffer
>> accounting as opposed to using hard coded values. Finally, split
>> TSO buffers out and provide an additional TX pool array for TSO.
>>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> ...
>> diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
>> index 099c89d..a2e21b3 100644
>> --- a/drivers/net/ethernet/ibm/ibmvnic.h
>> +++ b/drivers/net/ethernet/ibm/ibmvnic.h
>> @@ -917,11 +917,9 @@ struct ibmvnic_tx_pool {
>> int *free_map;
>> int consumer_index;
>> int producer_index;
>> - wait_queue_head_t ibmvnic_tx_comp_q;
>> - struct task_struct *work_thread;
>> struct ibmvnic_long_term_buff long_term_buff;
>> - struct ibmvnic_long_term_buff tso_ltb;
>> - int tso_index;
>> + int num_buffers;
>> + int buf_size;
>> };
>>
>> struct ibmvnic_rx_buff {
> Thomas, members like tso_ltb are used in the code at this point.
>
> You can't remove it here like this, because it makes your patch series
> non-bisectable. The tree should compile cleanly and work properly at
> each stage of your series.
>
> Thank you.
>
Thanks for your review, I'll send a reworked series soon.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net/ipv6: Handle onlink flag with multipath routes
From: David Ahern @ 2018-03-16 18:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20180316.123847.1371456393189460416.davem@davemloft.net>
On 3/16/18 9:38 AM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Fri, 16 Mar 2018 08:45:10 -0700
>
>> On 3/16/18 8:40 AM, David Miller wrote:
>>> Hmmm, this actually "accumulates" the flag rather than sets it.
>>>
>>> Have you thought about what should happen if the cfg has RTNH_F_ONLINK
>>> set?
>>
>> yes, that's why the test script adds cases with the ONLINK flag set for
>> both nexthops, then one with it on the first nexthop only, and one with
>> the flag only on the second nexthop.
>>
>> If you look at the full loop 'cfg' is the variable with the user data,
>> and r_cfg is the 'local loop version' so r_cfg.fc_flags gets reset for
>> each nexthop:
>>
>> while (rtnh_ok(rtnh, remaining)) {
>> memcpy(&r_cfg, cfg, sizeof(*cfg));
>> ...
>> r_cfg.fc_flags |= (rtnh->rtnh_flags & RTNH_F_ONLINK);
>> rt = ip6_route_info_create(&r_cfg, extack);
>
> Right.
>
>>> I think you should either change this logic to a true 'set', or adjust
>>> your commit message to address this aspect of the new behavior.
>>
>> I can update the commit message.
>
> Please do, thanks David.
>
And it looks like patch 1 needs to be in 'net'; did not realize the ipv6
ONLINK support is already in 4.16. I will send the patch adding tests
separately for net-next.
^ permalink raw reply
* pull request: bluetooth 2018-03-16
From: Johan Hedberg @ 2018-03-16 18:23 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
Hi Dave,
Here are a few more important Bluetooth driver fixes for the 4.16
kernel.
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 3d502067599f0db12e74e6646aee8728efe3e5be:
net/smc: simplify wait when closing listen socket (2018-03-15 09:49:13 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to e07c99b07ae85255d5c5bc2480fbd4c4e77f71bc:
Bluetooth: hci_bcm: Set pulsed_host_wake flag in sleep parameters (2018-03-15 19:39:37 +0100)
----------------------------------------------------------------
Hans de Goede (2):
Revert "Bluetooth: hci_bcm: Streamline runtime PM code"
Bluetooth: hci_bcm: Set pulsed_host_wake flag in sleep parameters
Takashi Iwai (1):
Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174
drivers/bluetooth/btusb.c | 2 +-
drivers/bluetooth/hci_bcm.c | 13 +++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)
From: David Miller @ 2018-03-16 18:30 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, torvalds, netdev
In-Reply-To: <20180316170614.5392-1-linux@dominikbrodowski.net>
From: Dominik Brodowski <linux@dominikbrodowski.net>
Date: Fri, 16 Mar 2018 18:05:52 +0100
> The rationale of this change is described in patch 1 of part 1[*] as follows:
>
> The syscall entry points to the kernel defined by SYSCALL_DEFINEx()
> and COMPAT_SYSCALL_DEFINEx() should only be called from userspace
> through kernel entry points, but not from the kernel itself. This
> will allow cleanups and optimizations to the entry paths *and* to
> the parts of the kernel code which currently need to pretend to be
> userspace in order to make use of syscalls.
>
> At present, these patches are based on v4.16-rc5; there is one trivial
> conflict against net-next. Dave, I presume that you prefer to take them
> through net-next? If you want to, I can re-base them against net-next.
> If you prefer otherwise, though, I can route them as part of my whole
> syscall series.
So the transformations themeselves are relatively trivial, so on that
aspect I don't have any problems with these changes.
But overall I have to wonder.
I imagine one of the things you'd like to do is declare that syscall
entries use a different (better) argument passing scheme. For
example, passing values in registers instead of on the stack.
But in situations where you split out the system call function
completely into one of these "helpers", the compiler is going
to have two choices:
1) Expand the helper into the syscall function inline, thus we end up
with two copies of the function.
2) Call the helper from the syscall function. Well, then the compiler
will need to pop the syscal obtained arguments from the registers
onto the stack.
So this doesn't seem like such a total win to me.
Maybe you can explain things better to ease my concerns.
About merging, I'm fine with you taking this via your tree. I do not
see there being any terribly difficult conflicts arising (famous
last words).
Thanks.
^ permalink raw reply
* Re: [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Sowmini Varadhan @ 2018-03-16 18:31 UTC (permalink / raw)
To: Kirill Tkhai
Cc: santosh.shilimkar, davem, netdev, linux-rdma, rds-devel, edumazet
In-Reply-To: <82d6e954-8043-078c-266c-2f1ac992f864@virtuozzo.com>
On (03/16/18 21:14), Kirill Tkhai wrote:
>
> I did the second version and sent you. Have you tried it?
I tried it briefly, and it works for the handful of testcases
that I tried, but I still think its very werid to register
as both a device and a subsys, esp in the light of the
warning in net_namespace.h
Thus I have to spend some time reviewing your patch,
and I cannot give you an answer in the next 5 minutes.
> Calling netdevice handler for every event is more disturbing,
> as number of events is several times bigger, than one more
> pernet exit method.
So you are saying there are scaling constraints on subsystems
that register for netdevice handlers. The disturbing part
of that is that it does not scale.
Thanks.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload
From: David Miller @ 2018-03-16 18:37 UTC (permalink / raw)
To: andrew; +Cc: grygorii.strashko, netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20180316002935.GB13119@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 16 Mar 2018 01:29:35 +0100
> On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote:
>> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host
>> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in
>> CPSW_CONTROL register. VLAN header encapsulation word has following format:
>>
>> HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)
>> HDR_PKT_CFI bits 28 - Header Packet VLAN CFI bit.
>> HDR_PKT_Vid bits 27-16 - Header Packet VLAN ID
>> PKT_Type bits 8-9 - Packet Type. Indicates whether the packet is
>> VLAN-tagged, priority-tagged, or non-tagged.
>> 00: VLAN-tagged packet
>> 01: Reserved
>> 10: Priority-tagged packet
>> 11: Non-tagged packet
>>
>> This feature can be used to implement TX VLAN offload in case of
>> VLAN-tagged packets and to insert VLAN tag in case Non-tagged packet was
>> received on port with PVID set. As per documentation, CPSW never modifies
>> packet data on Host egress (RX) and as result, without this feature
>> enabled, Host port will not be able to receive properly packets which
>> entered switch non-tagged through external Port with PVID set (when
>> non-tagged packet forwarded from external Port with PVID set to another
>> external Port - packet will be VLAN tagged properly).
>
> So, i think it is time to discuss the future of this driver. It should
> really be replaced by a switchdev/DSA driver. There are plenty of
> carrots for a new driver: Better statistics, working ethtool support
> for all the PHYs, better user experience, etc. But maybe now it is
> time for the stick. Should we Maintainers decide that no new features
> should be added to the existing drivers, just bug fixes?
Andrew, I totally share your concerns.
However, I think the reality is that at best we can strongly urge
people to do such a large amount of work such as writing a new
switchdev/DSA driver for this cpsw hardware.
We can't really compel them.
And a stick could have the opposite of it's intended effect. If still
nobody wants to do the switchdev/DSA driver, then this existing one
rots and even worse we can end up with an out-of-tree version of this
driver that has the changes (such as this one) that people want.
I'd like to see the switchdev/DSA driver for cpsw as much as you do,
but I am not convinced that rejecting patches like this one will
necessarily make that happen.
Also, it would be a completely different situation if we had someone
working on the switchdev/DSA version already.
So as it stands I really don't think we can block this patch.
Thank you.
^ permalink raw reply
* Re: [PATCH v2] netns: send uevent messages
From: David Miller @ 2018-03-16 18:41 UTC (permalink / raw)
To: christian.brauner
Cc: ebiederm, gregkh, netdev, linux-kernel, serge, avagin, ktkhai
In-Reply-To: <20180316125030.23624-1-christian.brauner@ubuntu.com>
From: Christian Brauner <christian.brauner@ubuntu.com>
Date: Fri, 16 Mar 2018 13:50:30 +0100
> +static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb,
> + struct netlink_ext_ack *extack)
> +{
> + int ret;
> + /* u64 to chars: 2^64 - 1 = 21 chars */
> + char buf[sizeof("SEQNUM=") + 21];
> + struct sk_buff *skbc;
I hate to be difficult, but please use reverse christmas tree ordering
for local variables.
> +static int uevent_net_rcv_skb(struct sk_buff *skb, struct nlmsghdr *nlh,
> + struct netlink_ext_ack *extack)
> +{
> + int ret;
> + struct net *net;
Likewise.
Thank you.
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Andrew Lunn @ 2018-03-16 18:42 UTC (permalink / raw)
To: Frantisek Rysanek; +Cc: netdev
In-Reply-To: <5AABF554.3719.302C6988@Frantisek.Rysanek.post.cz>
On Fri, Mar 16, 2018 at 05:48:20PM +0100, Frantisek Rysanek wrote:
> Dear polite inhabitants of the "netdev" mailing list,
>
> this is for a skunkworks project at the fringe of my job...
> More of a DIY hobby thing :-) I'm tinkering and having fun.
>
> The wizards from linux-ptp have taught me how to use the i210 for
> precise timestamping, which works fine at all copper speeds
> and likely also for gigabit fiber (SERDES) which the i210 natively
> supports (and which links fine).
>
> The catch is: I'm trying to get this to work on 100Base-FX :-)
> which is not a native interface for the i210.
> It can do SERDES only at 1Gb. But, it can do SGMII.
> I've managed to find an i210-based NIC from DeLock with an SFP slot
> and I've managed to find two models of 100Base-FX SGMII SFP's.
>
> My assumption is that the SFP's have SGMII instead of SERDES
> and MDIO instead of SPD I2C - and the manufacturers of the board
> and of the SFP's don't dispute that. Yet they have both vaguely
> warned me in advance that it would not work work :-)
> Well I've given it a try anyway, and I'm stuck at the MDIO level.
>
> With one of the SFP's, I know for a fact that it's based on the
> BCM5461S. The actual marking on the chip goes BCM5461SA... etc.
Hi Frantisek
This seems a bit odd. The SFP cage only has i2c, not MDIO. It is
possible to carry MDIO over i2c, which is what is done when the SFP
module is copper, not fibre. But you are doing 100Base-FX, so fibre.
The BCM5461 is a copper PHY. There are some PHYs which are designed to
act as translators. You can feed SERDES in one side, and get SGMII out
the other side, for example. Such PHYs can be used between a MAC and
an SFP socket. But from what i can find online about the BCM5461, it
does not have this capability.
Can you tell us the exact make/model of the DeLock card and the SFP
modules.
Andrew
^ permalink raw reply
* Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev
From: Grygorii Strashko @ 2018-03-16 18:42 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: David S. Miller, netdev, Greg Kroah-Hartman, Sekhar Nori,
linux-kernel, linux-omap
In-Reply-To: <72ff074d-b19d-6ae5-59c9-4aacaa8070fd@gmail.com>
On 03/16/2018 12:34 PM, Florian Fainelli wrote:
>
>
> On 03/16/2018 10:22 AM, Andrew Lunn wrote:
>> On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko wrote:
>>> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
>>> one netdevice, as result such drivers will produce warning during system
>>> boot and fail to connect second phy to netdevice when PHYLIB framework
>>> will try to create sysfs link netdev->phydev for second PHY
>>> in phy_attach_direct(), because sysfs link with the same name has been
>>> created already for the first PHY.
>>> As result, second CPSW external port will became unusable.
>>> This issue was introduced by commits:
>>> 5568363f0cb3 ("net: phy: Create sysfs reciprocal links for attached_dev/phydev"
>>> a3995460491d ("net: phy: Relax error checking on sysfs_create_link()"
>>
>> I wonder if it would be better to add a flag to the phydev that
>> indicates it is the second PHY connected to a MAC? Add a bit to
>> phydrv->mdiodrv.flags. If that bit is set, don't create the sysfs
>> file.
>
> We could indeed do that, I am fine with Grygorii's approach though in
> making the creation more silent and non fatal.
The link phydev->netdev still can be created. And failure to create links
is non fatal error in my opinion.
>
>>
>> For 99% of MAC drivers, having two PHYs is an error, so we want to aid
>> debug by reporting the sysfs error.
> That is true, either way is fine with me, really.
>
Error still will be reported, just not warning and it will be non-fatal.
So, with this patch set it will be possible now to continue boot (NFS for example),
connect to the system and gather logs.
--
regards,
-grygorii
^ permalink raw reply
* [PATCH net v2] net/ipv6: Handle onlink flag with multipath routes
From: David Ahern @ 2018-03-16 18:43 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
For multipath routes the ONLINK flag can be specified per nexthop in
rtnh_flags or globally in rtm_flags. Update ip6_route_multipath_add
to consider the ONLINK setting coming from rtnh_flags. Each loop over
nexthops the config for the sibling route is initialized to the global
config and then per nexthop settings overlayed. The flag is 'or'ed into
fib6_config to handle the ONLINK flag coming from either rtm_flags or
rtnh_flags.
Fixes: fc1e64e1092f ("net/ipv6: Add support for onlink flag")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v2
- updated commit message to reflect flag can be global or per-nexthop
and both need to be handled
net/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b3c1137ad0b8..b0d5c64e1978 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4112,6 +4112,7 @@ static int ip6_route_multipath_add(struct fib6_config *cfg,
r_cfg.fc_encap_type = nla_get_u16(nla);
}
+ r_cfg.fc_flags |= (rtnh->rtnh_flags & RTNH_F_ONLINK);
rt = ip6_route_info_create(&r_cfg, extack);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] cxgb4: notify fatal error to uld drivers
From: David Miller @ 2018-03-16 18:48 UTC (permalink / raw)
To: ganeshgr
Cc: netdev, nirranjan, dledford, jgg, linux-rdma, swise, indranil,
venkatesh
In-Reply-To: <1521190377-22823-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 16 Mar 2018 14:22:57 +0530
> notify uld drivers if the adapter encounters fatal
> error.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* [PATCH v2 net-next] selftests: Add multipath tests for onlink flag
From: David Ahern @ 2018-03-16 18:48 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
Add multipath tests for onlink flag: one test with onlink added to
both nexthops, then tests with onlink added to only 1 nexthop.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v2
- add ipv6 test for onlink flag set globally as well as per-nexthop
tools/testing/selftests/net/fib-onlink-tests.sh | 98 ++++++++++++++++++++++++-
1 file changed, 95 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index 06b1d7cc12cc..3991ad1a368d 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -56,7 +56,8 @@ TEST_NET6[2]=2001:db8:102
# connected gateway
CONGW[1]=169.254.1.254
-CONGW[2]=169.254.5.254
+CONGW[2]=169.254.3.254
+CONGW[3]=169.254.5.254
# recursive gateway
RECGW4[1]=169.254.11.254
@@ -232,6 +233,23 @@ run_ip()
log_test $? ${exp_rc} "${desc}"
}
+run_ip_mpath()
+{
+ local table="$1"
+ local prefix="$2"
+ local nh1="$3"
+ local nh2="$4"
+ local exp_rc="$5"
+ local desc="$6"
+
+ # dev arg may be empty
+ [ -n "${dev}" ] && dev="dev ${dev}"
+
+ run_cmd ip ro add table "${table}" "${prefix}"/32 \
+ nexthop via ${nh1} nexthop via ${nh2}
+ log_test $? ${exp_rc} "${desc}"
+}
+
valid_onlink_ipv4()
{
# - unicast connected, unicast recursive
@@ -243,13 +261,37 @@ valid_onlink_ipv4()
log_subsection "VRF ${VRF}"
- run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected"
+ run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[3]} ${NETIFS[p5]} 0 "unicast connected"
run_ip ${VRF_TABLE} ${TEST_NET4[2]}.2 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive"
log_subsection "VRF device, PBR table"
- run_ip ${PBR_TABLE} ${TEST_NET4[2]}.3 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected"
+ run_ip ${PBR_TABLE} ${TEST_NET4[2]}.3 ${CONGW[3]} ${NETIFS[p5]} 0 "unicast connected"
run_ip ${PBR_TABLE} ${TEST_NET4[2]}.4 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive"
+
+ # multipath version
+ #
+ log_subsection "default VRF - main table - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.5 \
+ "${CONGW[1]} dev ${NETIFS[p1]} onlink" \
+ "${CONGW[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.6 \
+ "${RECGW4[1]} dev ${NETIFS[p1]} onlink" \
+ "${RECGW4[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast recursive - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.7 \
+ "${CONGW[1]} dev ${NETIFS[p1]}" \
+ "${CONGW[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink first only"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.8 \
+ "${CONGW[1]} dev ${NETIFS[p1]} onlink" \
+ "${CONGW[2]} dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink second only"
}
invalid_onlink_ipv4()
@@ -289,6 +331,21 @@ run_ip6()
log_test $? ${exp_rc} "${desc}"
}
+run_ip6_mpath()
+{
+ local table="$1"
+ local prefix="$2"
+ local opts="$3"
+ local nh1="$4"
+ local nh2="$5"
+ local exp_rc="$6"
+ local desc="$7"
+
+ run_cmd ip -6 ro add table "${table}" "${prefix}"/128 "${opts}" \
+ nexthop via ${nh1} nexthop via ${nh2}
+ log_test $? ${exp_rc} "${desc}"
+}
+
valid_onlink_ipv6()
{
# - unicast connected, unicast recursive, v4-mapped
@@ -310,6 +367,40 @@ valid_onlink_ipv6()
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::4 ${V6ADDRS[p5]/::*}::64 ${NETIFS[p5]} 0 "unicast connected"
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::5 ${RECGW6[2]} ${NETIFS[p5]} 0 "unicast recursive"
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::6 ::ffff:${TEST_NET4IN6[2]} ${NETIFS[p5]} 0 "v4-mapped"
+
+ # multipath version
+ #
+ log_subsection "default VRF - main table - multipath"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::4 "onlink" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]}" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::5 "onlink" \
+ "${RECGW6[1]} dev ${NETIFS[p1]}" \
+ "${RECGW6[2]} dev ${NETIFS[p3]}" \
+ 0 "unicast recursive - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::6 "onlink" \
+ "::ffff:${TEST_NET4IN6[1]} dev ${NETIFS[p1]}" \
+ "::ffff:${TEST_NET4IN6[2]} dev ${NETIFS[p3]}" \
+ 0 "v4-mapped - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::7 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]} onlink" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink both nexthops"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::8 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]} onlink" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink first only"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::9 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]}" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink second only"
}
invalid_onlink_ipv6()
@@ -355,6 +446,7 @@ run_onlink_tests()
log_section "IPv6 onlink"
log_subsection "Valid onlink commands"
valid_onlink_ipv6
+ log_subsection "Invalid onlink commands"
invalid_onlink_ipv6
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Kirill Tkhai @ 2018-03-16 18:48 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: santosh.shilimkar, davem, netdev, linux-rdma, rds-devel, edumazet
In-Reply-To: <20180316183133.GP16870@oracle.com>
On 16.03.2018 21:31, Sowmini Varadhan wrote:
> On (03/16/18 21:14), Kirill Tkhai wrote:
>>
>> I did the second version and sent you. Have you tried it?
>
> I tried it briefly, and it works for the handful of testcases
> that I tried, but I still think its very werid to register
> as both a device and a subsys, esp in the light of the
> warning in net_namespace.h
I'll send a patch updating comment in net_namespace.h to clarify
the situation.
> Thus I have to spend some time reviewing your patch,
> and I cannot give you an answer in the next 5 minutes.
No problem, 5 minutes response never required. Thanks for
your review.
>> Calling netdevice handler for every event is more disturbing,
>> as number of events is several times bigger, than one more
>> pernet exit method.
>
> So you are saying there are scaling constraints on subsystems
> that register for netdevice handlers. The disturbing part
> of that is that it does not scale.
It does not scale. But if we do not work on this, nothing will change.
My point about less numbers is that every namespace will call this
new pernet->exit once. So, we will have 1 new function call per one
namespace.
Let's count numbers, if we have the same functionality implemented as netdev event.
Every net namespace has loopback dev. This device will be registered
and unregistered. The event handler will be called for many events
during this actions: NETDEV_REGISTER, NETDEV_UNREGISTER, NETDEV_POST_INIT, etc, etc.
So, if we use pernet exit, it leads us to signify less number of function calls.
Just this.
Kirill
^ permalink raw reply
* Re: [PATCH net 1/7] net: aquantia: Fix hardware reset when SPI may rarely hangup
From: David Miller @ 2018-03-16 18:50 UTC (permalink / raw)
To: igor.russkikh; +Cc: netdev, darcari, pavel.belous
In-Reply-To: <c0a6a02dd93bd4c19a2150884bdd73f5690fbc30.1521192913.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Fri, 16 Mar 2018 13:53:44 +0300
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> index 967f0fd..0da480b 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> @@ -80,15 +80,14 @@ int hw_atl_utils_initfw(struct aq_hw_s *self, const struct aq_fw_ops **fw_ops)
> static int hw_atl_utils_soft_reset_flb(struct aq_hw_s *self)
> {
> int k = 0;
> - u32 gsr;
> + u32 gsr, val;
Please preserve the reverse christmas tree ordering (longest to shortest line) for
variable declarations here.
^ permalink raw reply
* Re: [PATCH net 4/7] net: aquantia: Add aq_tx_clean_budget and valid budget handling logic
From: David Miller @ 2018-03-16 18:51 UTC (permalink / raw)
To: igor.russkikh; +Cc: netdev, darcari, pavel.belous
In-Reply-To: <33a3d54c44403ea0f56d4881341cb94cd22e08fc.1521192913.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Fri, 16 Mar 2018 13:53:47 +0300
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> index ebbaf63..5723f2c 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> @@ -36,6 +36,10 @@ static unsigned int aq_itr_rx;
> module_param_named(aq_itr_rx, aq_itr_rx, uint, 0644);
> MODULE_PARM_DESC(aq_itr_rx, "RX interrupt throttle rate");
>
> +unsigned aq_tx_clean_budget = 256;
> +module_param_named(aq_tx_clean_budget, aq_tx_clean_budget, uint, 0644);
> +MODULE_PARM_DESC(aq_tx_clean_budget, "Maximum descriptors to cleanup on TX at once");
> +
> static void aq_nic_update_ndev_stats(struct aq_nic_s *self);
Please do not add driver private module parameter knobs like this.
Instead, please use a existing, device agnostic, runtime,
configuration mechanism to control this.
Thank you.
^ permalink raw reply
* Re: [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Sowmini Varadhan @ 2018-03-16 18:53 UTC (permalink / raw)
To: Kirill Tkhai
Cc: santosh.shilimkar, davem, netdev, linux-rdma, rds-devel, edumazet
In-Reply-To: <856ac399-c934-6a14-1ae7-d921c449c4b1@virtuozzo.com>
On (03/16/18 21:48), Kirill Tkhai wrote:
>
> > Thus I have to spend some time reviewing your patch,
> > and I cannot give you an answer in the next 5 minutes.
>
> No problem, 5 minutes response never required. Thanks for
> your review.
thank you. I would like to take some time this weekend
to understand why v1 of your patch hit the null rtn,
but v2 did not (a superficial glance at the patch suggested
that you were registering twice in both cases, with just
a reordering, so I would like to understand the root-cause of
the null ptr deref with v1)
As for registering 2 times, that needs some comments to
provide guidance for other subsystems. e.g., I found the
large block comment in net-namespace.h very helpful, so lets
please clearly document what and why and when this should
be used.
--Sowmini
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload
From: Grygorii Strashko @ 2018-03-16 18:54 UTC (permalink / raw)
To: David Miller, andrew; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20180316.143739.424933240477251284.davem@davemloft.net>
On 03/16/2018 01:37 PM, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Fri, 16 Mar 2018 01:29:35 +0100
>
>> On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote:
>>> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host
>>> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in
>>> CPSW_CONTROL register. VLAN header encapsulation word has following format:
>>>
>>> HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)
>>> HDR_PKT_CFI bits 28 - Header Packet VLAN CFI bit.
>>> HDR_PKT_Vid bits 27-16 - Header Packet VLAN ID
>>> PKT_Type bits 8-9 - Packet Type. Indicates whether the packet is
>>> VLAN-tagged, priority-tagged, or non-tagged.
>>> 00: VLAN-tagged packet
>>> 01: Reserved
>>> 10: Priority-tagged packet
>>> 11: Non-tagged packet
>>>
>>> This feature can be used to implement TX VLAN offload in case of
>>> VLAN-tagged packets and to insert VLAN tag in case Non-tagged packet was
>>> received on port with PVID set. As per documentation, CPSW never modifies
>>> packet data on Host egress (RX) and as result, without this feature
>>> enabled, Host port will not be able to receive properly packets which
>>> entered switch non-tagged through external Port with PVID set (when
>>> non-tagged packet forwarded from external Port with PVID set to another
>>> external Port - packet will be VLAN tagged properly).
>>
>> So, i think it is time to discuss the future of this driver. It should
>> really be replaced by a switchdev/DSA driver. There are plenty of
>> carrots for a new driver: Better statistics, working ethtool support
>> for all the PHYs, better user experience, etc. But maybe now it is
>> time for the stick. Should we Maintainers decide that no new features
>> should be added to the existing drivers, just bug fixes?
>
> Andrew, I totally share your concerns.
>
> However, I think the reality is that at best we can strongly urge
> people to do such a large amount of work such as writing a new
> switchdev/DSA driver for this cpsw hardware.
>
> We can't really compel them.
>
> And a stick could have the opposite of it's intended effect. If still
> nobody wants to do the switchdev/DSA driver, then this existing one
> rots and even worse we can end up with an out-of-tree version of this
> driver that has the changes (such as this one) that people want.
Yeh :( This one was created to satisfy real customer use case.
So we'll have to carry it internally any way, but having it in LKML will
allow to involve broader number of people in review, testing and fixing.
And the same code will have to be part of dsa switch driver also - it
will be just more stable at time of migration to dsa.
>
> I'd like to see the switchdev/DSA driver for cpsw as much as you do,
> but I am not convinced that rejecting patches like this one will
> necessarily make that happen.
+1. Hope this work will be started as soon as possible.
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH net-next 0/3] net/smc: IPv6 support
From: David Miller @ 2018-03-16 19:00 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180316140641.7059-1-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Fri, 16 Mar 2018 15:06:38 +0100
> these smc patches for the net-next tree add IPv6 support.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix binding documentation for MDIO busses
From: David Miller @ 2018-03-16 19:02 UTC (permalink / raw)
To: andrew; +Cc: netdev, yxj790222
In-Reply-To: <1521219826-4156-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 16 Mar 2018 18:03:46 +0100
> The MDIO busses are switch proprieties and so should be inside the
> switch node. Fix the examples in the binding document.
>
> Reported-by: 尤晓杰 <yxj790222@163.com>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses")
Applied with "properties" spelling fixed.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: Simplified napi poll
From: David Miller @ 2018-03-16 19:03 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20180316172131.GA2285@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Fri, 16 Mar 2018 10:21:31 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> 1) Moved interrupt enable related code from octeon_process_droq_poll_cmd()
> to separate function octeon_enable_irq().
> 2) Removed wrapper function octeon_process_droq_poll_cmd(), and directlyi
> using octeon_droq_process_poll_pkts().
> 3) Removed unused macros POLL_EVENT_XXX.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Looks good, applied, thank you.
^ 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