* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: David Miller @ 2018-06-22 4:49 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, anders.roxell
In-Reply-To: <1529473363-4036-1-git-send-email-shannon.nelson@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Tue, 19 Jun 2018 22:42:41 -0700
> A couple of bad behaviors in the ipsec selftest were pointed out
> by Anders Roxell <anders.roxell@linaro.org> and are addressed here.
>
> Shannon Nelson (2):
> selftests: rtnetlink: hide complaint from terminated monitor
> selftests: rtnetlink: use a local IP address for IPsec tests
Series applied, but I wonder about patch #2.
The idea is that we don't make modifications to the actual system
networking configuration and therefore make changes that can't
possibly disrupt connectivity for the system under test.
Using a configured local IP address seems to subvert that.
^ permalink raw reply
* Re: [PATCH net-next] tcp: ignore rcv_rtt sample with old ts ecr value
From: David Miller @ 2018-06-22 4:45 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet, ncardwell
In-Reply-To: <20180620044250.33943-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Tue, 19 Jun 2018 21:42:50 -0700
> From: Wei Wang <weiwan@google.com>
>
> When receiving multiple packets with the same ts ecr value, only try
> to compute rcv_rtt sample with the earliest received packet.
> This is because the rcv_rtt calculated by later received packets
> could possibly include long idle time or other types of delay.
> For example:
> (1) server sends last packet of reply with TS val V1
> (2) client ACKs last packet of reply with TS ecr V1
> (3) long idle time passes
> (4) client sends next request data packet with TS ecr V1 (again!)
> At this time, the rcv_rtt computed on server with TS ecr V1 will be
> inflated with the idle time and should get ignored.
>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/7] Assorted rhashtables cleanups.
From: David Miller @ 2018-06-22 4:43 UTC (permalink / raw)
To: neilb; +Cc: tgraf, herbert, netdev, linux-kernel
In-Reply-To: <152929034948.23173.8671757672560065344.stgit@noble>
From: NeilBrown <neilb@suse.com>
Date: Mon, 18 Jun 2018 12:52:50 +1000
> Following 7 patches are selections from a recent RFC series I posted
> that have all received suitable Acks.
>
> The most visible changes are that rhashtable-types.h is now preferred
> for inclusion in include/linux/*.h rather than rhashtable.h, and
> that the full hash is used - no bits a reserved for a NULLS pointer.
Series applied to net-next, thanks Neil.
^ permalink raw reply
* Re: [PATCH net] net: sungem: fix rx checksum support
From: Eric Dumazet @ 2018-06-22 4:20 UTC (permalink / raw)
To: David Miller, edumazet; +Cc: netdev, mroos, malat, schwab, eric.dumazet
In-Reply-To: <20180620.143050.313454768369559179.davem@davemloft.net>
On 06/19/2018 10:30 PM, David Miller wrote:
> Tested-by: Andreas Schwab <schwab@linux-m68k.org>
>
> Applied and queued up for -stable, thanks Eric.
>
BTW, removing the FCS also means GRO is going to work, finally on this NIC ;)
GRO does not like packets with padding.
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-22 2:32 UTC (permalink / raw)
To: Siwei Liu
Cc: Cornelia Huck, Samudrala, Sridhar, Alexander Duyck, virtio-dev,
aaron.f.brown, Jiri Pirko, Jakub Kicinski, Netdev, qemu-devel,
virtualization, konrad.wilk, boris.ostrovsky, Joao Martins,
Venu Busireddy, vijay.balakrishna
In-Reply-To: <CADGSJ22B39JiS14L0yCYQ720-fZcwyUt1wCX1YO-6Y9FhmDKZg@mail.gmail.com>
On Thu, Jun 21, 2018 at 06:21:55PM -0700, Siwei Liu wrote:
> On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> > On Wed, 20 Jun 2018 22:48:58 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> >> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
> >> > In any case, I'm not sure anymore why we'd want the extra uuid.
> >>
> >> It's mostly so we can have e.g. multiple devices with same MAC
> >> (which some people seem to want in order to then use
> >> then with different containers).
> >>
> >> But it is also handy for when you assign a PF, since then you
> >> can't set the MAC.
> >>
> >
> > OK, so what about the following:
> >
> > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > that we have a new uuid field in the virtio-net config space
> > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > offer VIRTIO_NET_F_STANDBY_UUID if set
> > - when configuring, set the property to the group UUID of the vfio-pci
> > device
>
> If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
> to still expose UUID in the config space on virtio-pci?
Yes but guest is not supposed to read it.
> I'm not even sure if it's sane to expose group UUID on the PCI bridge
> where the corresponding vfio-pci device attached to for a guest which
> doesn't support the feature (legacy).
>
> -Siwei
Yes but you won't add the primary behind such a bridge.
>
> > - in the guest, use the uuid from the virtio-net device's config space
> > if applicable; else, fall back to matching by MAC as done today
> >
> > That should work for all virtio transports.
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Venu Busireddy @ 2018-06-22 2:25 UTC (permalink / raw)
To: Siwei Liu
Cc: Cornelia Huck, Michael S. Tsirkin, Samudrala, Sridhar,
Alexander Duyck, virtio-dev, aaron.f.brown, Jiri Pirko,
Jakub Kicinski, Netdev, qemu-devel, virtualization, konrad.wilk,
boris.ostrovsky, Joao Martins, vijay.balakrishna
In-Reply-To: <CADGSJ22B39JiS14L0yCYQ720-fZcwyUt1wCX1YO-6Y9FhmDKZg@mail.gmail.com>
On 2018-06-21 18:21:55 -0700, Siwei Liu wrote:
> On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> > On Wed, 20 Jun 2018 22:48:58 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> >> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
> >> > In any case, I'm not sure anymore why we'd want the extra uuid.
> >>
> >> It's mostly so we can have e.g. multiple devices with same MAC
> >> (which some people seem to want in order to then use
> >> then with different containers).
> >>
> >> But it is also handy for when you assign a PF, since then you
> >> can't set the MAC.
> >>
> >
> > OK, so what about the following:
> >
> > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > that we have a new uuid field in the virtio-net config space
> > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > offer VIRTIO_NET_F_STANDBY_UUID if set
> > - when configuring, set the property to the group UUID of the vfio-pci
> > device
>
> If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
> to still expose UUID in the config space on virtio-pci?
Why is it not safe? When we expose VIRTIO_NET_F_STANDBY_UUID, it is up
to the driver to decide if it wants to use it or not. If it does not
want to use the feature, it would also imply that the driver will not
be interested in the UUID value in the config space. So, the UUID will
be some piece of data that simply sits around; nobody cares for it.
> I'm not even sure if it's sane to expose group UUID on the PCI bridge
> where the corresponding vfio-pci device attached to for a guest which
> doesn't support the feature (legacy).
Unfortunately, you don't know beforehand if the guest will be a legacy
guest that doesn't support the feature. As is the case with the UUID in
the virtio-pci device's config space, the UUID in the bridge's config
space will/should be ignored by the legacy guest.
Venu
> > - in the guest, use the uuid from the virtio-net device's config space
> > if applicable; else, fall back to matching by MAC as done today
> >
> > That should work for all virtio transports.
^ permalink raw reply
* Re: [PATCH net V2 1/1] net/smc: coordinate wait queues for nonblocking connect
From: Cong Wang @ 2018-06-22 2:12 UTC (permalink / raw)
To: Ursula Braun
Cc: David Miller, Linux Kernel Network Developers, linux-s390,
schwidefsky, Heiko Carstens, raspl, Christoph Hellwig
In-Reply-To: <20180621142318.72681-1-ubraun@linux.ibm.com>
On Thu, Jun 21, 2018 at 7:23 AM, Ursula Braun <ubraun@linux.ibm.com> wrote:
> @@ -605,6 +606,13 @@ static int smc_connect(struct socket *sock, struct sockaddr *addr,
>
> smc_copy_sock_settings_to_clc(smc);
> tcp_sk(smc->clcsock->sk)->syn_smc = 1;
> + if (flags & O_NONBLOCK) {
> + rcu_read_lock();
> + smc->smcwq = rcu_dereference(sk->sk_wq);
> + rcu_assign_pointer(sock->sk->sk_wq,
> + rcu_dereference(smc->clcsock->sk->sk_wq));
> + rcu_read_unlock();
Are you really deref'ing any RCU pointer here?
^ permalink raw reply
* Re:
From: VIC J @ 2018-06-22 1:51 UTC (permalink / raw)
--
I'm soliciting your cooperation in a very important transaction
business that will benefit you and i, please i need your trust reply
for more details.
Kind regards.
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Siwei Liu @ 2018-06-22 1:21 UTC (permalink / raw)
To: Cornelia Huck
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Michael S. Tsirkin,
Jakub Kicinski, Samudrala, Sridhar, konrad.wilk, qemu-devel,
virtualization, Venu Busireddy, Netdev, boris.ostrovsky,
aaron.f.brown, Joao Martins
In-Reply-To: <20180621165913.7e3f4faa.cohuck@redhat.com>
On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Wed, 20 Jun 2018 22:48:58 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
>> > In any case, I'm not sure anymore why we'd want the extra uuid.
>>
>> It's mostly so we can have e.g. multiple devices with same MAC
>> (which some people seem to want in order to then use
>> then with different containers).
>>
>> But it is also handy for when you assign a PF, since then you
>> can't set the MAC.
>>
>
> OK, so what about the following:
>
> - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> that we have a new uuid field in the virtio-net config space
> - in QEMU, add a property for virtio-net that allows to specify a uuid,
> offer VIRTIO_NET_F_STANDBY_UUID if set
> - when configuring, set the property to the group UUID of the vfio-pci
> device
If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
to still expose UUID in the config space on virtio-pci?
I'm not even sure if it's sane to expose group UUID on the PCI bridge
where the corresponding vfio-pci device attached to for a guest which
doesn't support the feature (legacy).
-Siwei
> - in the guest, use the uuid from the virtio-net device's config space
> if applicable; else, fall back to matching by MAC as done today
>
> That should work for all virtio transports.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Martin KaFai Lau @ 2018-06-22 1:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621172523.6cd00ed1@cakuba.netronome.com>
On Thu, Jun 21, 2018 at 05:25:23PM -0700, Jakub Kicinski wrote:
> On Thu, 21 Jun 2018 16:58:15 -0700, Martin KaFai Lau wrote:
> > On Thu, Jun 21, 2018 at 04:07:19PM -0700, Jakub Kicinski wrote:
> > > On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> > > > On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > > > > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > > > > $ sudo bpftool map dump -p id 14
> > > > > > [{
> > > > > > "key": 0
> > > > > > },{
> > > > > > "value": {
> > > > > > "m": 1,
> > > > > > "n": 2,
> > > > > > "o": "c",
> > > > > > "p": [15,16,17,18,15,16,17,18
> > > > > > ],
> > > > > > "q": [[25,26,27,28,25,26,27,28
> > > > > > ],[35,36,37,38,35,36,37,38
> > > > > > ],[45,46,47,48,45,46,47,48
> > > > > > ],[55,56,57,58,55,56,57,58
> > > > > > ]
> > > > > > ],
> > > > > > "r": 1,
> > > > > > "s": 0x7ffff6f70568,
> > > > > > "t": {
> > > > > > "x": 5,
> > > > > > "y": 10
> > > > > > },
> > > > > > "u": 100,
> > > > > > "v": 20,
> > > > > > "w1": 0x7,
> > > > > > "w2": 0x3
> > > > > > }
> > > > > > }
> > > > > > ]
> > > > >
> > > > > I don't think this format is okay, JSON output is an API you shouldn't
> > > > > break. You can change the non-JSON output whatever way you like, but
> > > > > JSON must remain backwards compatible.
> > > > >
> > > > > The dump today has object per entry, e.g.:
> > > > >
> > > > > {
> > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > ],
> > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > ]
> > > > > }
> > > > >
> > > > > This format must remain, you may only augment it with new fields. E.g.:
> > > > >
> > > > > {
> > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > ],
> > > > > "key_struct":{
> > > > > "index":0
> > > > > },
Got a few questions.
When we support hashtab later, the key could be int
but reusing the name as "index" is weird.
The key could also be a struct (e.g. a struct to describe ip:port).
Can you suggest how the "key_struct" will look like?
> > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > ],
> > > > > "value_struct":{
> > > > > "src_ip":2,
If for the same map the user changes the "src_ip" to an array of int[4]
later (e.g. to support ipv6), it will become "src_ip": [1, 2, 3, 4].
Is it breaking backward compat?
i.e.
struct five_tuples {
- int src_ip;
+ int src_ip[4];
/* ... */
};
> > > > > "dst_ip:0
> > > > > }
> > > > > }
> > > > I am not sure how useful to have both "key|value" and "(key|value)_struct"
> > > > while most people would prefer "key_struct"/"value_struct" if it is
> > > > available.
> > >
> > > Agreed, it's not that useful, especially with the string-hex debacle :(
> > > It's just about the backwards compat.
> > >
> > > > How about introducing a new option, like "-b", to print the
> > > > map with BTF (if available) such that it won't break the existing
> > > > one (-j or -p) while the "-b" output can keep using the "key"
> > > > and "value".
> > > >
> > > > The existing json can be kept as is.
> > >
> > > That was my knee jerk reaction too, but on reflection it doesn't sound
> > > that great. We expect people with new-enough bpftool to use btf, so it
> > > should be available in the default output, without hiding it behind a
> > > switch. We could add a switch to hide the old output, but that doesn't
> > > give us back the names... What about Key and Value or k and v? Or
> > > key_fields and value_fields?
> > I thought the current default output is "plain" ;)
> > Having said that, yes, the btf is currently printed in json.
> >
> > Ideally, the default json output should do what most people want:
> > print btf and btf only (if it is available).
> > but I don't see a way out without new option if we need to
> > be backward compat :(
> >
> > Agree that showing the btf in the existing json output will be useful (e.g.
> > to hint people that BTF is available). If btf is showing in old json,
> > also agree that the names should be the same with the new json.
> > key_fields and value_fields may hint it has >1 fields though.
> > May be "formatted_key" and "formatted_value"?
>
> SGTM! Or even maybe as a "formatted" object?:
>
> {
> "key":["0x00","0x00","0x00","0x00",
> ],
> "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> ],
> "formatted":{
> "key":{
> "index":0
> },
> "value":{
> "src_ip":2,
> "dst_ip:0
> }
> }
hmm... that is an extra indentation (keep in mind that the "value" could
already have a few nested structs which itself consumes a few indentations)
but I guess adding another one may be ok-ish.
> }
>
> > > > > The name XYZ_struct may not be the best, perhaps you can come up with a
> > > > > better one?
> > > > >
> > > > > Does that make sense? Am I missing what you're doing here?
> > > > >
> > > > > One process note - please make sure you run checkpatch.pl --strict on
> > > > > bpftool patches before posting.
> > > > >
> > > > > Thanks for working on this!
>
^ permalink raw reply
* [PATCH 4/4] Documentation: e1000: Fix docs build error
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recent patch updated e1000 docs to rst format. Docs build (`make
htmldocs`) is currently failing due to this file with error:
(SEVERE/4) Unexpected section title.
This is because a section of the file is indented 2 spaces. Build error
can be cleared by aligning the text with column 0. While we are changing
these lines we can make sure line length does not exceed 72, that
newlines following headings are uniform, and that full stops are
followed by two spaces.
Align text with column 0, limit line length to 72, ensure two spaces
follow all full stops, ensure uniform use of newlines after heading.
Fixes commit (228046e76189 Documentation: e1000: Update kernel documentation)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e1000.rst | 75 +++++++++++++++---------------
1 file changed, 38 insertions(+), 37 deletions(-)
diff --git a/Documentation/networking/e1000.rst b/Documentation/networking/e1000.rst
index 55f28e5043b6..144b87eef153 100644
--- a/Documentation/networking/e1000.rst
+++ b/Documentation/networking/e1000.rst
@@ -355,57 +355,58 @@ previously mentioned to force the adapter to the same speed and duplex.
Additional Configurations
=========================
- Jumbo Frames
- ------------
- Jumbo Frames support is enabled by changing the MTU to a value larger than
- the default of 1500. Use the ifconfig command to increase the MTU size.
- For example::
+Jumbo Frames
+------------
+Jumbo Frames support is enabled by changing the MTU to a value larger
+than the default of 1500. Use the ifconfig command to increase the MTU
+size. For example::
ifconfig eth<x> mtu 9000 up
- This setting is not saved across reboots. It can be made permanent if
- you add::
+This setting is not saved across reboots. It can be made permanent if
+you add::
MTU=9000
- to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
- applies to the Red Hat distributions; other distributions may store this
- setting in a different location.
+to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
+applies to the Red Hat distributions; other distributions may store this
+setting in a different location.
- Notes:
- Degradation in throughput performance may be observed in some Jumbo frames
- environments. If this is observed, increasing the application's socket buffer
- size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
- See the specific application manual and /usr/src/linux*/Documentation/
- networking/ip-sysctl.txt for more details.
+Notes: Degradation in throughput performance may be observed in some
+Jumbo frames environments. If this is observed, increasing the
+application's socket buffer size and/or increasing the
+/proc/sys/net/ipv4/tcp_*mem entry values may help. See the specific
+application manual and /usr/src/linux*/Documentation/
+networking/ip-sysctl.txt for more details.
- - The maximum MTU setting for Jumbo Frames is 16110. This value coincides
- with the maximum Jumbo Frames size of 16128.
+- The maximum MTU setting for Jumbo Frames is 16110. This value
+ coincides with the maximum Jumbo Frames size of 16128.
- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
- poor performance or loss of link.
+- Using Jumbo frames at 10 or 100 Mbps is not supported and may result
+ in poor performance or loss of link.
- - Adapters based on the Intel(R) 82542 and 82573V/E controller do not
- support Jumbo Frames. These correspond to the following product names:
- Intel(R) PRO/1000 Gigabit Server Adapter
- Intel(R) PRO/1000 PM Network Connection
+- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
+ support Jumbo Frames. These correspond to the following product names:
+ Intel(R) PRO/1000 Gigabit Server Adapter Intel(R) PRO/1000 PM Network
+ Connection
- ethtool
- -------
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. The ethtool
- version 1.6 or later is required for this functionality.
+ethtool
+-------
+The driver utilizes the ethtool interface for driver configuration and
+diagnostics, as well as displaying statistical information. The ethtool
+version 1.6 or later is required for this functionality.
+
+The latest release of ethtool can be found from
+https://www.kernel.org/pub/software/network/ethtool/
- The latest release of ethtool can be found from
- https://www.kernel.org/pub/software/network/ethtool/
+Enabling Wake on LAN* (WoL)
+---------------------------
+WoL is configured through the ethtool* utility.
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is configured through the ethtool* utility.
+WoL will be enabled on the system during the next shut down or reboot.
+For this driver version, in order to enable WoL, the e1000 driver must be
+loaded when shutting down or rebooting the system.
- WoL will be enabled on the system during the next shut down or reboot.
- For this driver version, in order to enable WoL, the e1000 driver must be
- loaded when shutting down or rebooting the system.
Support
=======
--
2.17.1
^ permalink raw reply related
* [PATCH 3/4] Documentation: e100: Fix docs build error
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recent patch updated e100 docs to rst format. Docs build (`make
htmldocs`) is currently failing due to this file with error:
(SEVERE/4) Unexpected section title.
This is because a section of the file is indented 2 spaces. Build error
can be cleared by aligning the text with column 0. While we are changing
these lines we can make sure line length does not exceed 72, that
newlines following headings are uniform, and that full stops are
followed by two spaces.
Align text with column 0, limit line length to 72, ensure two spaces
follow all full stops, ensure uniform use of newlines after heading.
Fixes commit (85d63445f411 Documentation: e100: Update the Intel 10/100 driver doc)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e100.rst | 115 +++++++++++++++---------------
1 file changed, 58 insertions(+), 57 deletions(-)
diff --git a/Documentation/networking/e100.rst b/Documentation/networking/e100.rst
index 59b80608e27d..9708f5fa76de 100644
--- a/Documentation/networking/e100.rst
+++ b/Documentation/networking/e100.rst
@@ -87,83 +87,84 @@ Event Log Message Level: The driver uses the message level flag to log events
Additional Configurations
=========================
- Configuring the Driver on Different Distributions
- -------------------------------------------------
-
- Configuring a network driver to load properly when the system is started is
- distribution dependent. Typically, the configuration process involves adding
- an alias line to /etc/modprobe.d/*.conf as well as editing other system
- startup scripts and/or configuration files. Many popular Linux
- distributions ship with tools to make these changes for you. To learn the
- proper way to configure a network device for your system, refer to your
- distribution documentation. If during this process you are asked for the
- driver or module name, the name for the Linux Base Driver for the Intel
- PRO/100 Family of Adapters is e100.
-
- As an example, if you install the e100 driver for two PRO/100 adapters
- (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/
+Configuring the Driver on Different Distributions
+-------------------------------------------------
+
+Configuring a network driver to load properly when the system is started
+is distribution dependent. Typically, the configuration process involves
+adding an alias line to /etc/modprobe.d/*.conf as well as editing other
+system startup scripts and/or configuration files. Many popular Linux
+distributions ship with tools to make these changes for you. To learn
+the proper way to configure a network device for your system, refer to
+your distribution documentation. If during this process you are asked
+for the driver or module name, the name for the Linux Base Driver for
+the Intel PRO/100 Family of Adapters is e100.
+
+As an example, if you install the e100 driver for two PRO/100 adapters
+(eth0 and eth1), add the following to a configuration file in
+/etc/modprobe.d/::
alias eth0 e100
alias eth1 e100
- Viewing Link Messages
- ---------------------
- In order to see link messages and other Intel driver information on your
- console, you must set the dmesg level up to six. This can be done by
- entering the following on the command line before loading the e100 driver::
+Viewing Link Messages
+---------------------
- dmesg -n 6
-
- If you wish to see all messages issued by the driver, including debug
- messages, set the dmesg level to eight.
+In order to see link messages and other Intel driver information on your
+console, you must set the dmesg level up to six. This can be done by
+entering the following on the command line before loading the e100
+driver::
- NOTE: This setting is not saved across reboots.
+ dmesg -n 6
+If you wish to see all messages issued by the driver, including debug
+messages, set the dmesg level to eight.
- ethtool
- -------
+NOTE: This setting is not saved across reboots.
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. The ethtool
- version 1.6 or later is required for this functionality.
+ethtool
+-------
- The latest release of ethtool can be found from
- https://www.kernel.org/pub/software/network/ethtool/
+The driver utilizes the ethtool interface for driver configuration and
+diagnostics, as well as displaying statistical information. The ethtool
+version 1.6 or later is required for this functionality.
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is provided through the ethtool* utility. For instructions on enabling
- WoL with ethtool, refer to the ethtool man page.
+The latest release of ethtool can be found from
+https://www.kernel.org/pub/software/network/ethtool/
- WoL will be enabled on the system during the next shut down or reboot. For
- this driver version, in order to enable WoL, the e100 driver must be
- loaded when shutting down or rebooting the system.
+Enabling Wake on LAN* (WoL)
+---------------------------
+WoL is provided through the ethtool* utility. For instructions on
+enabling WoL with ethtool, refer to the ethtool man page. WoL will be
+enabled on the system during the next shut down or reboot. For this
+driver version, in order to enable WoL, the e100 driver must be loaded
+when shutting down or rebooting the system.
- NAPI
- ----
+NAPI
+----
- NAPI (Rx polling mode) is supported in the e100 driver.
+NAPI (Rx polling mode) is supported in the e100 driver.
- See https://wiki.linuxfoundation.org/networking/napi for more information
- on NAPI.
+See https://wiki.linuxfoundation.org/networking/napi for more
+information on NAPI.
- Multiple Interfaces on Same Ethernet Broadcast Network
- ------------------------------------------------------
+Multiple Interfaces on Same Ethernet Broadcast Network
+------------------------------------------------------
- Due to the default ARP behavior on Linux, it is not possible to have
- one system on two IP networks in the same Ethernet broadcast domain
- (non-partitioned switch) behave as expected. All Ethernet interfaces
- will respond to IP traffic for any IP address assigned to the system.
- This results in unbalanced receive traffic.
+Due to the default ARP behavior on Linux, it is not possible to have one
+system on two IP networks in the same Ethernet broadcast domain
+(non-partitioned switch) behave as expected. All Ethernet interfaces
+will respond to IP traffic for any IP address assigned to the system.
+This results in unbalanced receive traffic.
- If you have multiple interfaces in a server, either turn on ARP
- filtering by
+If you have multiple interfaces in a server, either turn on ARP
+filtering by
- (1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
- (this only works if your kernel's version is higher than 2.4.5), or
+(1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+ (this only works if your kernel's version is higher than 2.4.5), or
- (2) installing the interfaces in separate broadcast domains (either
- in different switches or in a switch partitioned to VLANs).
+(2) installing the interfaces in separate broadcast domains (either
+ in different switches or in a switch partitioned to VLANs).
Support
--
2.17.1
^ permalink raw reply related
* [PATCH 2/4] Documentation: e1000: Use correct heading adornment
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recently documentation file was converted to rst. The document title
has the incorrect heading adornment. From kernel docs:
* Please stick to this order of heading adornments:
1. ``=`` with overline for document title::
==============
Document title
==============
Add overline heading adornment to document title.
Fixes commit (228046e76189 Documentation: e1000: Update kernel documentation)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e1000.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/networking/e1000.rst b/Documentation/networking/e1000.rst
index 616848940e63..55f28e5043b6 100644
--- a/Documentation/networking/e1000.rst
+++ b/Documentation/networking/e1000.rst
@@ -1,3 +1,4 @@
+===========================================================
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
--
2.17.1
^ permalink raw reply related
* [PATCH 1/4] Documentation: e100: Use correct heading adornment
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recently documentation file was converted to rst. The document title
has the incorrect heading adornment. From kernel docs:
* Please stick to this order of heading adornments:
1. ``=`` with overline for document title::
==============
Document title
==============
Add overline heading adornment to document title.
Fixes commit (85d63445f411 Documentation: e100: Update the Intel 10/100 driver doc)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e100.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/networking/e100.rst b/Documentation/networking/e100.rst
index d4d837027925..59b80608e27d 100644
--- a/Documentation/networking/e100.rst
+++ b/Documentation/networking/e100.rst
@@ -1,3 +1,4 @@
+==============================================================
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
==============================================================
--
2.17.1
^ permalink raw reply related
* [PATCH 0/4] docs: e100[0] fix build errors
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
Hi Jonathan,
I may be a little confused here, I'm getting docs build failure on
Linus' mainline, linux-next, and your docs-next but different errors.
There seems to be patches to the first two trees that are not in your
docs-next tree?
Do networking docs typically go through your tree? Looks like
networking has done some conversion to rst that hasn't gone through your
tree. Or else my git skills are failing.
This patch set fixes current docs build failure on Linus' mainline
commit: (ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/kleikamp/linux-shaggy)
(FYI this is 8 commits after Linux 4.18-rc1).
And also same build errors on today's linux-next
8439c34f07a3 (tag: next-20180621, linux-next/master, linux-next) Add linux-next specific files for 20180621
I pulled your tree, just to make sure I'm pulling the correct one I got
a49d9c0ae46e (HEAD -> docs-next, tag: docs-4.18, corbet/docs-next) Documentation: document hung_task_panic kernel parameter
I split the patches in between the two drivers to enable use of the
'Fixes:' tag.
One question, is there are standard spacing after headings. I attempted
to maintain uniformity within each file but this has resulted in the two
files being different. One has no space after section headings
section heading
---------------
Some text with no newline.
While the other file uses a single newline after section headings.
While on the topic of newlines and headings; is there a correct number
of newlines to have _before_ a heading?
I did not find this information when looking at
Documentation/doc-guide/sphinx.rst
If there is a ruling on these newlines I can re-spin this set with an
added patch to fix all the newlines in both e1000.rst and e100.rst
thanks,
Tobin.
Tobin C. Harding (4):
Documentation: e100: Use correct heading adornment
Documentation: e1000: Use correct heading adornment
Documentation: e100: Fix docs build error
Documentation: e1000: Fix docs build error
Documentation/networking/e100.rst | 112 +++++++++++++++--------------
Documentation/networking/e1000.rst | 76 ++++++++++----------
2 files changed, 96 insertions(+), 92 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v1 1/1] VSOCK: fix loopback on big-endian systems
From: David Miller @ 2018-06-22 0:34 UTC (permalink / raw)
To: imbrenda
Cc: stefanha, jhansen, cavery, borntraeger, fiuczy, linux-kernel,
netdev
In-Reply-To: <1529502711-8028-1-git-send-email-imbrenda@linux.vnet.ibm.com>
From: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Date: Wed, 20 Jun 2018 15:51:51 +0200
> The dst_cid and src_cid are 64 bits, therefore 64 bit accessors should be
> used, and in fact in virtio_transport_common.c only 64 bit accessors are
> used. Using 32 bit accessors for 64 bit values breaks big endian systems.
>
> This patch fixes a wrong use of le32_to_cpu in virtio_transport_send_pkt.
>
> Fixes: b9116823189e85ccf384 ("VSOCK: add loopback to virtio_transport")
>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: davinci_cpdma: make function cpdma_desc_pool_create static
From: David Miller @ 2018-06-22 0:31 UTC (permalink / raw)
To: colin.king
Cc: f.fainelli, ivan.khoronzhuk, linux-omap, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180621171645.29734-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 21 Jun 2018 18:16:45 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The function cpdma_desc_pool_create is local to the source and does not
> need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> warning: symbol 'cpdma_desc_pool_create' was not declared. Should it
> be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks Colin.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Jakub Kicinski @ 2018-06-22 0:25 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621235746.dfq6kdtkogftw3ws@kafai-mbp.dhcp.thefacebook.com>
On Thu, 21 Jun 2018 16:58:15 -0700, Martin KaFai Lau wrote:
> On Thu, Jun 21, 2018 at 04:07:19PM -0700, Jakub Kicinski wrote:
> > On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> > > On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > > > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > > > $ sudo bpftool map dump -p id 14
> > > > > [{
> > > > > "key": 0
> > > > > },{
> > > > > "value": {
> > > > > "m": 1,
> > > > > "n": 2,
> > > > > "o": "c",
> > > > > "p": [15,16,17,18,15,16,17,18
> > > > > ],
> > > > > "q": [[25,26,27,28,25,26,27,28
> > > > > ],[35,36,37,38,35,36,37,38
> > > > > ],[45,46,47,48,45,46,47,48
> > > > > ],[55,56,57,58,55,56,57,58
> > > > > ]
> > > > > ],
> > > > > "r": 1,
> > > > > "s": 0x7ffff6f70568,
> > > > > "t": {
> > > > > "x": 5,
> > > > > "y": 10
> > > > > },
> > > > > "u": 100,
> > > > > "v": 20,
> > > > > "w1": 0x7,
> > > > > "w2": 0x3
> > > > > }
> > > > > }
> > > > > ]
> > > >
> > > > I don't think this format is okay, JSON output is an API you shouldn't
> > > > break. You can change the non-JSON output whatever way you like, but
> > > > JSON must remain backwards compatible.
> > > >
> > > > The dump today has object per entry, e.g.:
> > > >
> > > > {
> > > > "key":["0x00","0x00","0x00","0x00",
> > > > ],
> > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > ]
> > > > }
> > > >
> > > > This format must remain, you may only augment it with new fields. E.g.:
> > > >
> > > > {
> > > > "key":["0x00","0x00","0x00","0x00",
> > > > ],
> > > > "key_struct":{
> > > > "index":0
> > > > },
> > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > ],
> > > > "value_struct":{
> > > > "src_ip":2,
> > > > "dst_ip:0
> > > > }
> > > > }
> > > I am not sure how useful to have both "key|value" and "(key|value)_struct"
> > > while most people would prefer "key_struct"/"value_struct" if it is
> > > available.
> >
> > Agreed, it's not that useful, especially with the string-hex debacle :(
> > It's just about the backwards compat.
> >
> > > How about introducing a new option, like "-b", to print the
> > > map with BTF (if available) such that it won't break the existing
> > > one (-j or -p) while the "-b" output can keep using the "key"
> > > and "value".
> > >
> > > The existing json can be kept as is.
> >
> > That was my knee jerk reaction too, but on reflection it doesn't sound
> > that great. We expect people with new-enough bpftool to use btf, so it
> > should be available in the default output, without hiding it behind a
> > switch. We could add a switch to hide the old output, but that doesn't
> > give us back the names... What about Key and Value or k and v? Or
> > key_fields and value_fields?
> I thought the current default output is "plain" ;)
> Having said that, yes, the btf is currently printed in json.
>
> Ideally, the default json output should do what most people want:
> print btf and btf only (if it is available).
> but I don't see a way out without new option if we need to
> be backward compat :(
>
> Agree that showing the btf in the existing json output will be useful (e.g.
> to hint people that BTF is available). If btf is showing in old json,
> also agree that the names should be the same with the new json.
> key_fields and value_fields may hint it has >1 fields though.
> May be "formatted_key" and "formatted_value"?
SGTM! Or even maybe as a "formatted" object?:
{
"key":["0x00","0x00","0x00","0x00",
],
"value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
],
"formatted":{
"key":{
"index":0
},
"value":{
"src_ip":2,
"dst_ip:0
}
}
}
> > > > The name XYZ_struct may not be the best, perhaps you can come up with a
> > > > better one?
> > > >
> > > > Does that make sense? Am I missing what you're doing here?
> > > >
> > > > One process note - please make sure you run checkpatch.pl --strict on
> > > > bpftool patches before posting.
> > > >
> > > > Thanks for working on this!
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Martin KaFai Lau @ 2018-06-21 23:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621160719.2cfb4b58@cakuba.netronome.com>
On Thu, Jun 21, 2018 at 04:07:19PM -0700, Jakub Kicinski wrote:
> On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> > On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > > $ sudo bpftool map dump -p id 14
> > > > [{
> > > > "key": 0
> > > > },{
> > > > "value": {
> > > > "m": 1,
> > > > "n": 2,
> > > > "o": "c",
> > > > "p": [15,16,17,18,15,16,17,18
> > > > ],
> > > > "q": [[25,26,27,28,25,26,27,28
> > > > ],[35,36,37,38,35,36,37,38
> > > > ],[45,46,47,48,45,46,47,48
> > > > ],[55,56,57,58,55,56,57,58
> > > > ]
> > > > ],
> > > > "r": 1,
> > > > "s": 0x7ffff6f70568,
> > > > "t": {
> > > > "x": 5,
> > > > "y": 10
> > > > },
> > > > "u": 100,
> > > > "v": 20,
> > > > "w1": 0x7,
> > > > "w2": 0x3
> > > > }
> > > > }
> > > > ]
> > >
> > > I don't think this format is okay, JSON output is an API you shouldn't
> > > break. You can change the non-JSON output whatever way you like, but
> > > JSON must remain backwards compatible.
> > >
> > > The dump today has object per entry, e.g.:
> > >
> > > {
> > > "key":["0x00","0x00","0x00","0x00",
> > > ],
> > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > ]
> > > }
> > >
> > > This format must remain, you may only augment it with new fields. E.g.:
> > >
> > > {
> > > "key":["0x00","0x00","0x00","0x00",
> > > ],
> > > "key_struct":{
> > > "index":0
> > > },
> > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > ],
> > > "value_struct":{
> > > "src_ip":2,
> > > "dst_ip:0
> > > }
> > > }
> > I am not sure how useful to have both "key|value" and "(key|value)_struct"
> > while most people would prefer "key_struct"/"value_struct" if it is
> > available.
>
> Agreed, it's not that useful, especially with the string-hex debacle :(
> It's just about the backwards compat.
>
> > How about introducing a new option, like "-b", to print the
> > map with BTF (if available) such that it won't break the existing
> > one (-j or -p) while the "-b" output can keep using the "key"
> > and "value".
> >
> > The existing json can be kept as is.
>
> That was my knee jerk reaction too, but on reflection it doesn't sound
> that great. We expect people with new-enough bpftool to use btf, so it
> should be available in the default output, without hiding it behind a
> switch. We could add a switch to hide the old output, but that doesn't
> give us back the names... What about Key and Value or k and v? Or
> key_fields and value_fields?
I thought the current default output is "plain" ;)
Having said that, yes, the btf is currently printed in json.
Ideally, the default json output should do what most people want:
print btf and btf only (if it is available).
but I don't see a way out without new option if we need to
be backward compat :(
Agree that showing the btf in the existing json output will be useful (e.g.
to hint people that BTF is available). If btf is showing in old json,
also agree that the names should be the same with the new json.
key_fields and value_fields may hint it has >1 fields though.
May be "formatted_key" and "formatted_value"?
>
> > > The name XYZ_struct may not be the best, perhaps you can come up with a
> > > better one?
> > >
> > > Does that make sense? Am I missing what you're doing here?
> > >
> > > One process note - please make sure you run checkpatch.pl --strict on
> > > bpftool patches before posting.
> > >
> > > Thanks for working on this!
^ permalink raw reply
* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
From: Nikolay Aleksandrov @ 2018-06-21 23:35 UTC (permalink / raw)
To: David Miller, garrmcnu; +Cc: netdev, bridge, jiri, linux-kernel
In-Reply-To: <20180622.072056.1223319763674661318.davem@davemloft.net>
On 06/22/2018 01:20 AM, David Miller wrote:
> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
>
>> br_port_get_rtnl() can return NULL if the network device is not a bridge
>> port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
>> br_port_fill_slave_info() callbacks dereference this pointer without
>> checking. Currently this is not a problem because slave devices always
>> set this flag. Add null check in case these conditions ever changye.
>>
>> Detected by CoverityScan, CID 1339613 ("Dereference null return value")
>>
>> Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
>
> I don't think this is reasonable.
>
> The bridge code will never, ever, install a slave that doesn't have
> that bit set. It's the most fundamental aspect of how these objects
> are managed.
>
+1
This keeps coming up, here's the previous one:
https://patchwork.ozlabs.org/patch/896046/
Please do a more thorough check if these conditions can actually occur.
In this case, as Dave said, they cannot.
To be explicit as with the patch I mentioned above:
Nacked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
You can find more info in my reply to the patch above.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()
From: Stephen Hemminger @ 2018-06-21 23:21 UTC (permalink / raw)
To: David Miller; +Cc: jiri, nikolay, netdev, bridge, linux-kernel, garrmcnu
In-Reply-To: <20180622.072056.1223319763674661318.davem@davemloft.net>
On Fri, 22 Jun 2018 07:20:56 +0900 (KST)
David Miller <davem@davemloft.net> wrote:
> From: Garry McNulty <garrmcnu@gmail.com>
> Date: Thu, 21 Jun 2018 21:14:27 +0100
>
> > br_port_get_rtnl() can return NULL if the network device is not a bridge
> > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and
> > br_port_fill_slave_info() callbacks dereference this pointer without
> > checking. Currently this is not a problem because slave devices always
> > set this flag. Add null check in case these conditions ever change.
> >
> > Detected by CoverityScan, CID 1339613 ("Dereference null return value")
> >
> > Signed-off-by: Garry McNulty <garrmcnu@gmail.com>
>
> I don't think this is reasonable.
>
> The bridge code will never, ever, install a slave that doesn't have
> that bit set. It's the most fundamental aspect of how these objects
> are managed.
Agree with dave. Workarounds for static tools are ok if they don't introduce
other paths. But if your fix introduces another error path which can never
be reached, it is hurting not helping.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Jakub Kicinski @ 2018-06-21 23:07 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621225117.dhrkrtmkfbeihbe4@kafai-mbp.dhcp.thefacebook.com>
On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > $ sudo bpftool map dump -p id 14
> > > [{
> > > "key": 0
> > > },{
> > > "value": {
> > > "m": 1,
> > > "n": 2,
> > > "o": "c",
> > > "p": [15,16,17,18,15,16,17,18
> > > ],
> > > "q": [[25,26,27,28,25,26,27,28
> > > ],[35,36,37,38,35,36,37,38
> > > ],[45,46,47,48,45,46,47,48
> > > ],[55,56,57,58,55,56,57,58
> > > ]
> > > ],
> > > "r": 1,
> > > "s": 0x7ffff6f70568,
> > > "t": {
> > > "x": 5,
> > > "y": 10
> > > },
> > > "u": 100,
> > > "v": 20,
> > > "w1": 0x7,
> > > "w2": 0x3
> > > }
> > > }
> > > ]
> >
> > I don't think this format is okay, JSON output is an API you shouldn't
> > break. You can change the non-JSON output whatever way you like, but
> > JSON must remain backwards compatible.
> >
> > The dump today has object per entry, e.g.:
> >
> > {
> > "key":["0x00","0x00","0x00","0x00",
> > ],
> > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > ]
> > }
> >
> > This format must remain, you may only augment it with new fields. E.g.:
> >
> > {
> > "key":["0x00","0x00","0x00","0x00",
> > ],
> > "key_struct":{
> > "index":0
> > },
> > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > ],
> > "value_struct":{
> > "src_ip":2,
> > "dst_ip:0
> > }
> > }
> I am not sure how useful to have both "key|value" and "(key|value)_struct"
> while most people would prefer "key_struct"/"value_struct" if it is
> available.
Agreed, it's not that useful, especially with the string-hex debacle :(
It's just about the backwards compat.
> How about introducing a new option, like "-b", to print the
> map with BTF (if available) such that it won't break the existing
> one (-j or -p) while the "-b" output can keep using the "key"
> and "value".
>
> The existing json can be kept as is.
That was my knee jerk reaction too, but on reflection it doesn't sound
that great. We expect people with new-enough bpftool to use btf, so it
should be available in the default output, without hiding it behind a
switch. We could add a switch to hide the old output, but that doesn't
give us back the names... What about Key and Value or k and v? Or
key_fields and value_fields?
> > The name XYZ_struct may not be the best, perhaps you can come up with a
> > better one?
> >
> > Does that make sense? Am I missing what you're doing here?
> >
> > One process note - please make sure you run checkpatch.pl --strict on
> > bpftool patches before posting.
> >
> > Thanks for working on this!
^ permalink raw reply
* Counsel
From: Frederic Betrisey @ 2018-06-21 14:58 UTC (permalink / raw)
To: netdev
I am counsel to late Henry and I have something very urgent to discuss with you. Thank you!
Regards,
Frederic Betrisey
^ permalink raw reply
* Re: [PATCH 0/2] xen-netfront: Fix issues with commit f599c64fdf7d
From: David Miller @ 2018-06-21 22:56 UTC (permalink / raw)
To: ross.lagerwall; +Cc: netdev, boris.ostrovsky, jgross, xen-devel, linux-kernel
In-Reply-To: <20180621130021.27029-1-ross.lagerwall@citrix.com>
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Date: Thu, 21 Jun 2018 14:00:19 +0100
> Fix a couple of issues with commit f599c64fdf7d ("xen-netfront: Fix race
> between device setup and open").
Series applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Martin KaFai Lau @ 2018-06-21 22:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621145935.41ff8974@cakuba.netronome.com>
On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > $ sudo bpftool map dump -p id 14
> > [{
> > "key": 0
> > },{
> > "value": {
> > "m": 1,
> > "n": 2,
> > "o": "c",
> > "p": [15,16,17,18,15,16,17,18
> > ],
> > "q": [[25,26,27,28,25,26,27,28
> > ],[35,36,37,38,35,36,37,38
> > ],[45,46,47,48,45,46,47,48
> > ],[55,56,57,58,55,56,57,58
> > ]
> > ],
> > "r": 1,
> > "s": 0x7ffff6f70568,
> > "t": {
> > "x": 5,
> > "y": 10
> > },
> > "u": 100,
> > "v": 20,
> > "w1": 0x7,
> > "w2": 0x3
> > }
> > }
> > ]
>
> I don't think this format is okay, JSON output is an API you shouldn't
> break. You can change the non-JSON output whatever way you like, but
> JSON must remain backwards compatible.
>
> The dump today has object per entry, e.g.:
>
> {
> "key":["0x00","0x00","0x00","0x00",
> ],
> "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> ]
> }
>
> This format must remain, you may only augment it with new fields. E.g.:
>
> {
> "key":["0x00","0x00","0x00","0x00",
> ],
> "key_struct":{
> "index":0
> },
> "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> ],
> "value_struct":{
> "src_ip":2,
> "dst_ip:0
> }
> }
I am not sure how useful to have both "key|value" and "(key|value)_struct"
while most people would prefer "key_struct"/"value_struct" if it is
available.
How about introducing a new option, like "-b", to print the
map with BTF (if available) such that it won't break the existing
one (-j or -p) while the "-b" output can keep using the "key"
and "value".
The existing json can be kept as is.
>
> The name XYZ_struct may not be the best, perhaps you can come up with a
> better one?
>
> Does that make sense? Am I missing what you're doing here?
>
> One process note - please make sure you run checkpatch.pl --strict on
> bpftool patches before posting.
>
> Thanks for working on this!
^ 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