* Re: [PATCH net-next 1/2] net: linkwatch: add check for netdevice being present to linkwatch_do_dev
From: Geert Uytterhoeven @ 2018-09-19 8:48 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Andrew Lunn, David S. Miller, netdev,
Geert Uytterhoeven
In-Reply-To: <11beeaa9-57d5-e641-9486-f2ba202d0998@gmail.com>
On Tue, Sep 18, 2018 at 9:56 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> When bringing down the netdevice (incl. detaching it) and calling
> netif_carrier_off directly or indirectly the latter triggers an
> asynchronous linkwatch event.
> This linkwatch event eventually may fail to access chip registers in
> the ndo_get_stats/ndo_get_stats64 callback because the device isn't
> accessible any longer, see call trace in [0].
>
> To prevent this scenario don't check for IFF_UP only, but also make
> sure that the netdevice is present.
>
> [0] https://lists.openwall.net/netdev/2018/03/15/62
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Survived 100 suspend/resume cycles on sh73a0/kzm9g and r8a73a4/ape6evm.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: call state machine synchronously in phy_stop
From: Geert Uytterhoeven @ 2018-09-19 8:49 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, Andrew Lunn, David S. Miller, netdev,
Geert Uytterhoeven
In-Reply-To: <a58e1448-0a10-b7a1-ccca-ca99f146c8ea@gmail.com>
On Tue, Sep 18, 2018 at 9:56 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> phy_stop() may be called e.g. when suspending, therefore all needed
> actions should be performed synchronously. Therefore add a synchronous
> call to the state machine.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Survived 100 suspend/resume cycles on sh73a0/kzm9g and r8a73a4/ape6evm.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] net: ibm: remove redundant local variables 'act_nr_of_entries' and 'act_pages'
From: zhong jiang @ 2018-09-19 14:30 UTC (permalink / raw)
To: davem; +Cc: dougmill, netdev, linux-kernel
That local variable are never used after being assigned.
hence it should be redundant and can be removed.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/ibm/ehea/ehea_qmr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_qmr.c b/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
index a0820f7..5e4e371 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
@@ -125,7 +125,7 @@ struct ehea_cq *ehea_create_cq(struct ehea_adapter *adapter,
struct ehea_cq *cq;
struct h_epa epa;
u64 *cq_handle_ref, hret, rpage;
- u32 act_nr_of_entries, act_pages, counter;
+ u32 counter;
int ret;
void *vpage;
@@ -140,8 +140,6 @@ struct ehea_cq *ehea_create_cq(struct ehea_adapter *adapter,
cq->adapter = adapter;
cq_handle_ref = &cq->fw_handle;
- act_nr_of_entries = 0;
- act_pages = 0;
hret = ehea_h_alloc_resource_cq(adapter->handle, &cq->attr,
&cq->fw_handle, &cq->epas);
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Robin Murphy @ 2018-09-19 14:37 UTC (permalink / raw)
To: Laurentiu Tudor, devicetree@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Madalin-cristian Bucur, Roy Pledge, Leo Li, shawnguo@kernel.org,
davem@davemloft.net
In-Reply-To: <fd8ab351-46aa-f73e-593b-502a57de1975@nxp.com>
On 19/09/18 15:18, Laurentiu Tudor wrote:
> Hi Robin,
>
> On 19.09.2018 16:25, Robin Murphy wrote:
>> Hi Laurentiu,
>>
>> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>
>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>>> and consists mostly in important driver fixes and the required device
>>> tree updates. It touches several subsystems and consists of three main
>>> parts:
>>> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
>>> reserved memory areas, fixes and defered probe support
>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>>> consisting in misc dma mapping related fixes and probe ordering
>>> - addition of the actual arm smmu device tree node together with
>>> various adjustments to the device trees
>>>
>>> Performance impact
>>>
>>> Running iperf benchmarks in a back-to-back setup (both sides
>>> having smmu enabled) on a 10GBps port show an important
>>> networking performance degradation of around %40 (9.48Gbps
>>> linerate vs 5.45Gbps). If you need performance but without
>>> SMMU support you can use "iommu.passthrough=1" to disable
>>> SMMU.
>>>
>>> USB issue and workaround
>>>
>>> There's a problem with the usb controllers in these chips
>>> generating smaller, 40-bit wide dma addresses instead of the 48-bit
>>> supported at the smmu input. So you end up in a situation where the
>>> smmu is mapped with 48-bit address translations, but the device
>>> generates transactions with clipped 40-bit addresses, thus smmu
>>> context faults are triggered. I encountered a similar situation for
>>> mmc that I managed to fix in software [1] however for USB I did not
>>> find a proper place in the code to add a similar fix. The only
>>> workaround I found was to add this kernel parameter which limits the
>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
>>> This workaround if far from ideal, so any suggestions for a code
>>> based workaround in this area would be greatly appreciated.
>>
>> If you have a nominally-64-bit device with a
>> narrower-than-the-main-interconnect link in front of it, that should
>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
>> provided the interconnect hierarchy can be described appropriately (or
>> at least massaged sufficiently to satisfy the binding), e.g.:
>>
>> / {
>> ...
>>
>> soc {
>> ranges;
>> dma-ranges = <0 0 10000 0>;
>>
>> dev_48bit { ... };
>>
>> periph_bus {
>> ranges;
>> dma-ranges = <0 0 100 0>;
>>
>> dev_40bit { ... };
>> };
>> };
>> };
>>
>> and if that fails to work as expected (except for PCI hosts where
>> handling dma-ranges properly still needs sorting out), please do let us
>> know ;)
>>
>
> Just to confirm, Is this [1] the change I was supposed to test?
Not quite - dma-ranges is only valid for nodes representing a bus, so
putting it directly in the USB device nodes doesn't work (FWIW that's
why PCI is broken, because the parser doesn't expect the
bus-as-leaf-node case). That's teh point of that intermediate simple-bus
node represented by "periph_bus" in my example (sorry, I should have put
compatibles in to make it clearer) - often that's actually true to life
(i.e. "soc" is something like a CCI and "periph_bus" is something like
an AXI NIC gluing a bunch of lower-bandwidth DMA masters to one of the
CCI ports) but at worst it's just a necessary evil to make the binding
happy (if it literally only represents the point-to-point link between
the device master port and interconnect slave port).
> Because if so, I'm still seeing context faults [2] with what looks like
> clipped to 40-bits addresses. :-(
> IIRC, the usb subsystem explicitly set 64-bit dma masks which in turn
> will be limited to the SMMU input size of 48-bit. Won't that overwrite
> the default dma mask derived from dma-ranges?
Indeed it will, but those default masks were effectively only ever a
best-effort thing anyway - it's an ease-of-implementation detail that
bus_dma_mask is not currently reflected in the device masks, although we
may eventually change that; the crucial part is that the DMA ops
implementations know about it and should now enforce it properly
regardless of whether drivers set something wider.
Robin.
>
> ---
> Best Regards, Laurentiu
>
> [1] -----------------------------------------------------------------
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index 3bdea0470f69..a214c3df37fd 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -612,6 +612,7 @@
> compatible = "snps,dwc3";
> reg = <0x0 0x2f00000 0x0 0x10000>;
> interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> + dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
> dr_mode = "host";
> snps,quirk-frame-length-adjustment = <0x20>;
> snps,dis_rxdet_inp3_quirk;
> @@ -621,6 +622,7 @@
> compatible = "snps,dwc3";
> reg = <0x0 0x3000000 0x0 0x10000>;
> interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> + dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
> dr_mode = "host";
> snps,quirk-frame-length-adjustment = <0x20>;
> snps,dis_rxdet_inp3_quirk;
> @@ -630,6 +632,7 @@
> compatible = "snps,dwc3";
> reg = <0x0 0x3100000 0x0 0x10000>;
> interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
> + dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x00000000>;
> dr_mode = "host";
> snps,quirk-frame-length-adjustment = <0x20>;
> snps,dis_rxdet_inp3_quirk;
>
> [2] -----------------------------------------------------------------
> [ 2.090577] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
> [ 2.096064] xhci-hcd xhci-hcd.0.auto: new USB bus registered,
> assigned bus number 2
> [ 2.103720] xhci-hcd xhci-hcd.0.auto: Host supports USB 3.0 SuperSpeed
> [ 2.110346] arm-smmu 9000000.iommu: Unhandled context fault:
> fsr=0x402, iova=0xffffffb000, fsynr=0x1b0000, cb=3
> [ 2.120449] usb usb2: We don't know the algorithms for LPM for this
> host, disabling LPM.
> [ 2.128717] hub 2-0:1.0: USB hub found
> [ 2.132473] hub 2-0:1.0: 1 port detected
> [ 2.136527] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
> [ 2.142014] xhci-hcd xhci-hcd.1.auto: new USB bus registered,
> assigned bus number 3
> [ 2.149747] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220f66d hci
> version 0x100 quirks 0x0000000002010010
> [ 2.159149] xhci-hcd xhci-hcd.1.auto: irq 50, io mem 0x03000000
> [ 2.165284] hub 3-0:1.0: USB hub found
> [ 2.169039] hub 3-0:1.0: 1 port detected
> [ 2.173051] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
> [ 2.178536] xhci-hcd xhci-hcd.1.auto: new USB bus registered,
> assigned bus number 4
> [ 2.186193] xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed
> [ 2.192809] arm-smmu 9000000.iommu: Unhandled context fault:
> fsr=0x402, iova=0xffffffb000, fsynr=0x1f0000, cb=4
> [ 2.192822] usb usb4: We don't know the algorithms for LPM for this
> host, disabling LPM.
> [ 2.211141] hub 4-0:1.0: USB hub found
> [ 2.214896] hub 4-0:1.0: 1 port detected
> [ 2.218935] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
> [ 2.224425] xhci-hcd xhci-hcd.2.auto: new USB bus registered,
> assigned bus number 5
> [ 2.232153] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f66d hci
> version 0x100 quirks 0x0000000002010010
> [ 2.241562] xhci-hcd xhci-hcd.2.auto: irq 51, io mem 0x03100000
> [ 2.247694] hub 5-0:1.0: USB hub found
> [ 2.251449] hub 5-0:1.0: 1 port detected
> [ 2.255458] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
> [ 2.260945] xhci-hcd xhci-hcd.2.auto: new USB bus registered,
> assigned bus number 6
> [ 2.268601] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0 SuperSpeed
> [ 2.275218] arm-smmu 9000000.iommu: Unhandled context fault:
> fsr=0x402, iova=0xffffffb000, fsynr=0x110000, cb=5
> [ 2.275230] usb usb6: We don't know the algorithms for LPM for this
> host, disabling LPM.
>
>
>>> The patch set is based on net-next so, if generally agreed, I'd suggest
>>> to get the patches through the netdev tree after getting all the Acks.
>>>
>>> [1]
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F10506627%2F&data=02%7C01%7Claurentiu.tudor%40nxp.com%7C63c4e1dfc126488eb4ba08d61e336607%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636729603447603039&sdata=XhjOX9aLgoe%2BSTBgZztv6zCz0vMebSXW%2Fnb2QcD5shY%3D&reserved=0
>>>
>>>
>>> Laurentiu Tudor (21):
>>> soc/fsl/qman: fixup liodns only on ppc targets
>>> soc/fsl/bman: map FBPR area in the iommu
>>> soc/fsl/qman: map FQD and PFDR areas in the iommu
>>> soc/fsl/qman-portal: map CENA area in the iommu
>>> soc/fsl/qbman: add APIs to retrieve the probing status
>>> soc/fsl/qman_portals: defer probe after qman's probe
>>> soc/fsl/bman_portals: defer probe after bman's probe
>>> soc/fsl/qbman_portals: add APIs to retrieve the probing status
>>> fsl/fman: backup and restore ICID registers
>>> fsl/fman: add API to get the device behind a fman port
>>> dpaa_eth: defer probing after qbman
>>> dpaa_eth: base dma mappings on the fman rx port
>>> dpaa_eth: fix iova handling for contiguous frames
>>> dpaa_eth: fix iova handling for sg frames
>>> dpaa_eth: fix SG frame cleanup
>>> arm64: dts: ls1046a: add smmu node
>>> arm64: dts: ls1043a: add smmu node
>>> arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
>>> arm64: dts: ls104x: add missing dma ranges property
>>> arm64: dts: ls104x: add iommu-map to pci controllers
>>> arm64: dts: ls104x: make dma-coherent global to the SoC
>>>
>>> .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 ++++++-
>>> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 48 +++++++
>>> .../net/ethernet/freescale/dpaa/dpaa_eth.c | 136 ++++++++++++------
>>> drivers/net/ethernet/freescale/fman/fman.c | 35 ++++-
>>> drivers/net/ethernet/freescale/fman/fman.h | 4 +
>>> .../net/ethernet/freescale/fman/fman_port.c | 14 ++
>>> .../net/ethernet/freescale/fman/fman_port.h | 2 +
>>> drivers/soc/fsl/qbman/bman_ccsr.c | 23 +++
>>> drivers/soc/fsl/qbman/bman_portal.c | 20 ++-
>>> drivers/soc/fsl/qbman/qman_ccsr.c | 30 ++++
>>> drivers/soc/fsl/qbman/qman_portal.c | 35 +++++
>>> include/soc/fsl/bman.h | 16 +++
>>> include/soc/fsl/qman.h | 17 +++
>>> 13 files changed, 379 insertions(+), 53 deletions(-)
>> >
^ permalink raw reply
* [PATCH] ieee802154: remove a redundant local variable 'i'
From: zhong jiang @ 2018-09-19 14:41 UTC (permalink / raw)
To: davem; +Cc: stefan, alex.aring, netdev, linux-kernel
The local variable 'i' is never used after being assigned.
hence it should be redundant adn can be removed.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/ieee802154/nl802154.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 99f6c25..5b90151 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -445,7 +445,6 @@ static int nl802154_send_wpan_phy(struct cfg802154_registered_device *rdev,
{
struct nlattr *nl_cmds;
void *hdr;
- int i;
hdr = nl802154hdr_put(msg, portid, seq, flags, cmd);
if (!hdr)
@@ -508,7 +507,6 @@ static int nl802154_send_wpan_phy(struct cfg802154_registered_device *rdev,
if (!nl_cmds)
goto nla_put_failure;
- i = 0;
#define CMD(op, n) \
do { \
if (rdev->ops->op) { \
--
1.7.12.4
^ permalink raw reply related
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Jiri Benc @ 2018-09-19 9:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Johannes Berg
In-Reply-To: <20180918131212.20266-4-johannes@sipsolutions.net>
On Tue, 18 Sep 2018 15:12:11 +0200, Johannes Berg wrote:
> static int validate_nla(const struct nlattr *nla, int maxtype,
> const struct nla_policy *policy,
> - const char **error_msg)
> + struct netlink_ext_ack *extack, bool *extack_set)
Can't the extack_set be included in the struct netlink_ext_ack? One less
parameter to pass around and the NL_SET_* macros could check this on
their own.
This way, it can be also easily turned to a more complex mechanism,
such as the one Marcelo proposed.
Thanks,
Jiri
^ permalink raw reply
* Bridge connectivity interruptions while devices join or leave the bridge
From: Johannes Wienke @ 2018-09-19 9:10 UTC (permalink / raw)
To: netdev
I am sorry for probably misusing this list, but I couldn't find any
other mailing list suitable for asking in-detail Linux networking
questions. As I am not subscribed, please CC me in a potential reply.
I am currently tracking down a connectivity issues of docker containers
on a custom bridge network, which I could reduce to the Linux network
stack without docker being involved.
The situation that I am observing is the following: I have a bridge
device, which is connected to the outer world using forwarding and
masquerading (so the bridge does not contain the outgoing network
interface of the host). This bridge is used to perform network
operations by a long-running process, which is restricted to this bridge
using network namespaces and veth devices (exactly what docker does
internally). What I see is that every time a (virtual) network device is
added to or removed from the bridge, the communication of the
long-running process is interrupted.
I have created two scripts that can be used to replicate the situation.
They are available at:
https://gist.github.com/languitar/9ac8dc5c8db7cf4a89e1546f6e32ca7b
setup.bash sets up the bridge, veth devices, network namespace and the
iptables rules to replicate the network setup and simulates the
long-running process by periodically performing (volatile) UDP DNS
requests in a while loop.
When launching this script, all DNS requests should succeed and you
should see success messages at a regular pace.
To simulate devices joining and leaving the bridge, you can start
interruptor.bash.
As soon as this script is running, you can observe that DNS requests
will be delayed frequently and some of them even fail. In a parallel
pcap you would see that sometimes the UDP packages from the DNS lookup
are not routed to the outside world, but instead end up at the bridge
device without ever leaving the host system.
Can someone explain what is happening here and why adding and removing
devices to a bridge results in the connectivity issues? How to avoid
this behavior? I'd be glad for any hint on that.
Kind regards
Johannes
--
Johannes Wienke, Researcher at CoR-Lab / CITEC, Bielefeld University
Address: Inspiration 1, D-33619 Bielefeld, Germany (Room 1.307)
Phone: +49 521 106-67277
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Johannes Berg @ 2018-09-19 9:15 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev
In-Reply-To: <20180919111048.092376b2@redhat.com>
On Wed, 2018-09-19 at 11:10 +0200, Jiri Benc wrote:
> On Tue, 18 Sep 2018 15:12:11 +0200, Johannes Berg wrote:
> > static int validate_nla(const struct nlattr *nla, int maxtype,
> > const struct nla_policy *policy,
> > - const char **error_msg)
> > + struct netlink_ext_ack *extack, bool *extack_set)
>
> Can't the extack_set be included in the struct netlink_ext_ack? One less
> parameter to pass around and the NL_SET_* macros could check this on
> their own.
No, I don't think it can or should.
For one, having the NL_SET_* macros check it on their own will already
not work - as we discussed over in the NLA_REJECT thread, we do need to
be able to override the data, e.g. if somebody does
NL_SET_ERR_MSG(extack, "warning: deprecated command");
err = nla_parse(..., extack);
and nla_parse() sets a new message. Thus, hiding all the logic in there
already will not work, and is also IMHO rather unexpected. Normally,
*later* messages should win, not *earlier* ones - and that doesn't
require any tracking, just setting them unconditionally.
It's just a side effect of how we do the recursive validation here that
we want *earlier* messages to win (but only within this code piece - if
a previous message was set, we want it to be overwritten by nla_parse!).
It might be possible to do this differently, in theory, but all the ways
I've tried to come up with so far made the code vastly more complex.
johannes
^ permalink raw reply
* Re: [RFC] net;sched: Try to find idle cpu for RPS to handle packets
From: Eric Dumazet @ 2018-09-19 14:55 UTC (permalink / raw)
To: Kirill Tkhai
Cc: Peter Zijlstra, David Miller, Daniel Borkmann, tom, netdev, LKML
In-Reply-To: <153736009982.24033.13696245431713246950.stgit@localhost.localdomain>
On Wed, Sep 19, 2018 at 5:29 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> Many workloads have polling mode of work. The application
> checks for incomming packets from time to time, but it also
> has a work to do, when there is no packets. This RFC
> tries to develop an idea to queue RPS packets on idle
> CPU in the the L3 domain of the consumer, so backlog
> processing of the packets and the application can execute
> in parallel.
>
> We require this in case of network cards does not
> have enough RX queues to cover all online CPUs (this seems
> to be the most cards), and get_rps_cpu() actually chooses
> remote cpu, and SMP interrupt is sent. Here we may try
> our best, and to find idle CPU nearly the consumer's CPU.
> Note, that in case of consumer works in poll mode and it
> does not waits for incomming packets, its CPU will be not
> idle, while CPU of a sleeping consumer may be idle. So,
> not polling consumers will still be able to have skb
> handled on its CPU.
>
> In case of network card has many queues, the device
> interrupts will come on consumer's CPU, and this patch
> won't try to find idle cpu for them.
>
> I've tried simple netperf test for this:
> netserver -p 1234
> netperf -L 127.0.0.1 -p 1234 -l 100
>
> Before:
> 87380 16384 16384 100.00 60323.56
> 87380 16384 16384 100.00 60388.46
> 87380 16384 16384 100.00 60217.68
> 87380 16384 16384 100.00 57995.41
> 87380 16384 16384 100.00 60659.00
>
> After:
> 87380 16384 16384 100.00 64569.09
> 87380 16384 16384 100.00 64569.25
> 87380 16384 16384 100.00 64691.63
> 87380 16384 16384 100.00 64930.14
> 87380 16384 16384 100.00 62670.15
>
> The difference between best runs is +7%,
> the worst runs differ +8%.
>
> What do you think about following somehow in this way?
Hi Kirill
In my experience, scheduler has a poor view of softirq processing
happening on various cpus.
A cpu spending 90% of its cycles processing IRQ might be considered 'idle'
So please run a real workload (it is _very_ uncommon anyone set up RPS
on lo interface !)
Like 400 or more concurrent netperf -t TCP_RR on a 10Gbit NIC.
Thanks.
PS: Idea of playing with L3 domains is interesting, I have personally
tried various strategies in the past but none of them
demonstrated a clear win.
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: net: qcom: Add binding for shared mdio bus
From: Wang, Dongsheng @ 2018-09-19 9:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, timur@kernel.org, davem@davemloft.net,
Zheng, Joey, netdev@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20180918123545.GA29092@lunn.ch>
On 2018/9/18 20:35, Andrew Lunn wrote:
>>> If you want to describe the MDIO controller, then you embed a mdio
>>> subnode into your Ethernet MAC node:
>>>
>>> emac0: ethernet@feb20000 {
>>> mdio {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> phy0: ethernet-phy@0 {
>>> reg = <0>;
>>> };
>>> };
>>> };
>>>
>>> And then each Ethernet MAC controller refers to their appropriate PHY
>>> device tree node using a phy-handle property to point to either their
>>> own MDIO controller, or another MAC's MDIO controller.
>> Sorry, I do not understand how phy-handle point to MDIO controller,
>> because phy-handle is defined to point to a phy.
> The MAC driver does not care what MDIO controller a PHY is on. All you
> need to do to register the PHY is:
Yes, these are all things that must be done, and emac driver will
connect phy when mac up.
If we had a separate MDIO controller, the MAC would not care about MDIO
bus. But MDIO is integrated within the EMAC, and emac driver maintains
the mdio.
Each EMAC do their mdio register/unregister. But in the shared scenario,
the EMACs that use the shared bus do not need to create an MDIO and
cannot release the Shared bus.
In device tree environment as you and Florian said. Just use phy-handle
get the phy_node.
The EMAC would not care about the phy come from which MDIO bus because
the phy device gets from the device_node match(phy-handle). And if the
phy_dev cannot get through phy_node means, the mdio bus is not ready.
But ACPI environment my understand is this:
First method. EMAC driver gets the shared MDIO bus, and maintain it.
The second way, EMAC match the phy_dev from the name.
These patch series try to use the FIRST way. Now I prefer to use the
second way to do the shared function.
I will rework this patchset and maybe patches will be a delay for a few
days.
Cheers,
Dongsheng
> phy_node = of_parse_phandle(np, "phy-handle", 0);
> phy_interface = of_get_phy_mode(np);
> phydev = of_phy_connect(dev, phy_node,
> &handle_link_change, 0,
> phy_interface);
>
> Andrew
>
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Johannes Berg @ 2018-09-19 9:25 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <20180919033733.GK4590@localhost.localdomain>
On Wed, 2018-09-19 at 00:37 -0300, Marcelo Ricardo Leitner wrote:
> Did you consider indicating the message level, and only overwrite the
> message that is already in there if the new message level is higher
> than the current one?
Hmm, no, I guess I didn't - I'm not even sure I understand what you're
saying.
This code in itself generates no "warning" messages; that was just a
construct we discussed in the NLA_REJECT thread, e.g. if you say (like I
just also wrote in my reply to Jiri):
NL_SET_ERR_MSG(extack, "warning: deprecated command");
err = nla_parse(..., extack);
if (err)
return err;
/* do something */
return 0;
Here you could consider the message there a warning that's transported
out even if we return 0, but if we return with a failure from
nla_parse() (or nla_validate instead if you wish), then that failure
message "wins".
> This way the first to set an Error message will have it, and Warning
> messages would be overwritten by such if needed. But it also would
> cause the first warning to be held, and not the last one, as it does
> today. We want the first error, but the last warning otherwise.
>
> It would not be possible to overwrite if new_msglvl >= cur_msglvl
> because then it would trigger the initial issue again, so some extra
> logic would be needed to solve this.
That sounds way more complex than what I'm doing now?
Note, like I said above, this isn't *generic* in any way. This code here
will only ever set error messages that should "win".
I suppose we could - technically - make that generic, in that we could
have both
NLA_SET_WARN_MSG(extack, "...");
NLA_SET_ERR_MSG(extack, "...");
and keep track of warning vs. error; however, just like my first version
of the NLA_REJECT patch, that would break existing code.
I also don't think that we actually *need* this complexity in general.
It should almost always be possible (and realistically, pretty easy) to
structure your code in a way that warning messages only go out if no
error message overwrites them. The only reason we were ever even
discussing this was that in NLA_REJECT I missed the fact that somebody
could've set a message before and thus would keep it rather than
overwrite it, which was a change in behaviour.
Now, with this patch, all I'm doing is changing the internal behaviour
of nla_parse/nla_validate - externally, it still overwrites any existing
message if an error occurs, but internally it keeps the inner-most
error.
Why is this? Consider this:
static const struct nla_policy inner_policy[] = {
[INNER_FLAG] = { .type = NLA_REJECT,
.validation_data = "must not set this flag" }
};
static const struct nla_policy outer_policy[] = {
[OUTER_NESTING] = { .type = NLA_NESTED, .len = INNER_MAX,
.validation_data = inner_policy,
};
Now if you invoke nla_parse/nla_validate with a message like this
[ OUTER_NESTING => [ INNER_FLAG, ... ], ... ]
you'd get "must not set this flag" with the error offset pointing to
that; if I didn't do this construction here with inner messages winning,
you'd get "Attribute failed policy validation" with the error offset
pointing to the "OUTER_NESTING" attribute, that's pretty useless.
>From an external API POV though, nla_validate/nla_parse will continue to
unconditionally overwrite any existing "warning" messages with errors,
if such occurred. They just won't overwrite their own messages when
returning from a nested policy validation.
johannes
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Jiri Benc @ 2018-09-19 9:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1537348525.10305.15.camel@sipsolutions.net>
On Wed, 19 Sep 2018 11:15:25 +0200, Johannes Berg wrote:
> For one, having the NL_SET_* macros check it on their own will already
> not work - as we discussed over in the NLA_REJECT thread, we do need to
> be able to override the data, e.g. if somebody does
>
> NL_SET_ERR_MSG(extack, "warning: deprecated command");
> err = nla_parse(..., extack);
>
> and nla_parse() sets a new message. Thus, hiding all the logic in there
> already will not work, and is also IMHO rather unexpected. Normally,
> *later* messages should win, not *earlier* ones - and that doesn't
> require any tracking, just setting them unconditionally.
>
> It's just a side effect of how we do the recursive validation here that
> we want *earlier* messages to win (but only within this code piece - if
> a previous message was set, we want it to be overwritten by nla_parse!).
Fair enough.
> It might be possible to do this differently, in theory, but all the ways
> I've tried to come up with so far made the code vastly more complex.
Wouldn't still make sense to store the flag in the struct
netlink_ext_ack, though? The way the parameters are passed around in
this patch looks ugly. And adding more users of the flag later (there
may be other cases when we want the earlier messages to be preserved)
would mean adding parameters all around, while the flag in the struct
would be readily available.
I don't have a strong opinion on this, just the patch seems to be
inelegant.
Jiri
^ permalink raw reply
* [PATCH net-next 03/12] Documentation/bindings: net: marvell-pp2: update the IRQs description
From: Antoine Tenart @ 2018-09-19 9:27 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919092711.22296-1-antoine.tenart@bootlin.com>
This patch updates the interrupts part of the Marvell PPv2 driver
bindings documentation, to keep it in sync with the driver.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
.../devicetree/bindings/net/marvell-pp2.txt | 45 +++++++++++++------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt
index fc019df0d863..b78397669320 100644
--- a/Documentation/devicetree/bindings/net/marvell-pp2.txt
+++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt
@@ -31,7 +31,7 @@ required.
Required properties (port):
-- interrupts: interrupt for the port
+- interrupts: interrupt(s) for the port
- port-id: ID of the port from the MAC point of view
- gop-port-id: only for marvell,armada-7k-pp2, ID of the port from the
GOP (Group Of Ports) point of view. This ID is used to index the
@@ -43,10 +43,12 @@ Optional properties (port):
- marvell,loopback: port is loopback mode
- phy: a phandle to a phy node defining the PHY address (as the reg
property, a single integer).
-- interrupt-names: if more than a single interrupt for rx is given, must
- be the name associated to the interrupts listed. Valid
- names are: "tx-cpu0", "tx-cpu1", "tx-cpu2", "tx-cpu3",
- "rx-shared", "link".
+- interrupt-names: if more than a single interrupt for is given, must be the
+ name associated to the interrupts listed. Valid names are:
+ "hifX", with X in [0..8], and "link". The names "tx-cpu0",
+ "tx-cpu1", "tx-cpu2", "tx-cpu3" and "rx-shared" are supported
+ for backward compatibility but shouldn't be used for new
+ additions.
- marvell,system-controller: a phandle to the system controller.
Example for marvell,armada-375-pp2:
@@ -89,9 +91,14 @@ cpm_ethernet: ethernet@0 {
<ICU_GRP_NSR 43 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 47 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 51 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2",
- "tx-cpu3", "rx-shared";
+ <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 59 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 63 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 67 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 71 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 129 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
port-id = <0>;
gop-port-id = <0>;
};
@@ -101,9 +108,14 @@ cpm_ethernet: ethernet@0 {
<ICU_GRP_NSR 44 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 48 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 52 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2",
- "tx-cpu3", "rx-shared";
+ <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 60 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 64 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 68 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 72 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 128 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
port-id = <1>;
gop-port-id = <2>;
};
@@ -113,9 +125,14 @@ cpm_ethernet: ethernet@0 {
<ICU_GRP_NSR 45 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 49 IRQ_TYPE_LEVEL_HIGH>,
<ICU_GRP_NSR 53 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2",
- "tx-cpu3", "rx-shared";
+ <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 61 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 65 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 69 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 73 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 127 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
port-id = <2>;
gop-port-id = <3>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 00/12] net: mvpp2: improve the interrupt usage
From: Antoine Tenart @ 2018-09-19 9:26 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
Hi all,
This series aims to improve the interrupts descriptions and usage in the
Marvell PPv2 driver.
- Before the series interrupts were named after their s/w usage,
which in fact can be configured. The series rename all those
interrupts and add a description of the ones left over.
- In PPv2 the interrupts are mapped to vectors. Those vectors were
directly mapped to a given CPU, and per-cpu accesses were done. While
this worked on our cases, the registers accesses mapped to the vectors
are not actually linked to a given CPU. They instead are linked to
what is called a "s/w thread". The series modify this so that the s/w
threads are used instead of the CPU numbers, by adding an indirection.
This means we now can have systems with more CPUs than s/w threads.
This is based on today's net-next, and was tested on various boards
using both versions of the PPv2 engine.
Two more patches will be coming, to update the device trees describing a
PPv2 engine. The patches are ready, but will go through a different
tree. I'll send them once this series will be accepted. This is not an
issue as the PPv2 driver keeps the dt bindings backward compatibility.
Thanks!
Antoine
Antoine Tenart (12):
net: mvpp2: increase the number of s/w threads to 9
net: mvpp2: rename the IRQs to match the hardware
Documentation/bindings: net: marvell-pp2: update the IRQs description
net: mvpp2: do not update the queue mode while probing
net: mvpp2: fix the number of queues per cpu for PPv2.2
net: mvpp2: cpu should always be unsigned
net: mvpp2: make the per-cpu helpers static
net: mvpp2: make mvpp2_read_relaxed static
net: mvpp2: do not use the CPU number to access the per-thread
registers
net: mvpp2: map the CPUs to threads
net: mvpp2: handle cases where more CPUs are available than s/w
threads
net: mvpp2: rename mvpp2_percpu function to mvpp2_thread
.../devicetree/bindings/net/marvell-pp2.txt | 45 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 27 +-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 431 +++++++++++-------
3 files changed, 315 insertions(+), 188 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 07/12] net: mvpp2: make the per-cpu helpers static
From: Antoine Tenart @ 2018-09-19 9:27 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919092711.22296-1-antoine.tenart@bootlin.com>
The Marvell PPv2 driver has per-cpu functions. As they only are used in
the main file, make them static and remove their prototype from the
header.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 7 -------
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++---
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 57fea9193a49..5247f2d1f573 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -1099,13 +1099,6 @@ u32 mvpp2_read(struct mvpp2 *priv, u32 offset);
u32 mvpp2_read_relaxed(struct mvpp2 *priv, u32 offset);
-void mvpp2_percpu_write(struct mvpp2 *priv, unsigned int cpu, u32 offset,
- u32 data);
-u32 mvpp2_percpu_read(struct mvpp2 *priv, unsigned int cpu, u32 offset);
-
-void mvpp2_percpu_write_relaxed(struct mvpp2 *priv, unsigned int cpu,
- u32 offset, u32 data);
-
void mvpp2_dbgfs_init(struct mvpp2 *priv, const char *name);
void mvpp2_dbgfs_cleanup(struct mvpp2 *priv);
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 8d4e5d0c0ad8..f5edde2994e0 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -123,19 +123,19 @@ u32 mvpp2_read_relaxed(struct mvpp2 *priv, u32 offset)
* MVPP2_TXQ_PREF_BUF_REG (related to MVPP2_TXQ_NUM_REG)
* MVPP2_TXQ_PREF_BUF_REG (related to MVPP2_TXQ_NUM_REG)
*/
-void mvpp2_percpu_write(struct mvpp2 *priv, unsigned int cpu,
+static void mvpp2_percpu_write(struct mvpp2 *priv, unsigned int cpu,
u32 offset, u32 data)
{
writel(data, priv->swth_base[cpu] + offset);
}
-u32 mvpp2_percpu_read(struct mvpp2 *priv, unsigned int cpu,
+static u32 mvpp2_percpu_read(struct mvpp2 *priv, unsigned int cpu,
u32 offset)
{
return readl(priv->swth_base[cpu] + offset);
}
-void mvpp2_percpu_write_relaxed(struct mvpp2 *priv, unsigned int cpu,
+static void mvpp2_percpu_write_relaxed(struct mvpp2 *priv, unsigned int cpu,
u32 offset, u32 data)
{
writel_relaxed(data, priv->swth_base[cpu] + offset);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 1/3] net: phy: phylink: ensure the carrier is off when starting phylink
From: Antoine Tenart @ 2018-09-19 9:39 UTC (permalink / raw)
To: davem, linux, andrew, f.fainelli
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919093933.24411-1-antoine.tenart@bootlin.com>
Phylink made an assumption about the carrier state being down when
calling phylink_start(). If this assumption isn't satisfied, the
internal phylink state could misbehave and a net device could end up not
being functional.
This patch fixes this by explicitly calling netif_carrier_off() in
phylink_start().
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/phy/phylink.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 3ba5cf2a8a5f..1d01e0c625a5 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -901,6 +901,9 @@ void phylink_start(struct phylink *pl)
phylink_an_mode_str(pl->link_an_mode),
phy_modes(pl->link_config.interface));
+ /* Always set the carrier off */
+ netif_carrier_off(pl->netdev);
+
/* Apply the link configuration to the MAC when starting. This allows
* a fixed-link to start with the correct parameters, and also
* ensures that we set the appropriate advertisement for Serdes links.
--
2.17.1
^ permalink raw reply related
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Jiri Benc @ 2018-09-19 9:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: Marcelo Ricardo Leitner, netdev
In-Reply-To: <1537349117.10305.25.camel@sipsolutions.net>
On Wed, 19 Sep 2018 11:25:17 +0200, Johannes Berg wrote:
> Now, with this patch, all I'm doing is changing the internal behaviour
> of nla_parse/nla_validate - externally, it still overwrites any existing
> message if an error occurs, but internally it keeps the inner-most
> error.
Ah, okay, that answers my question about putting the flag into the
ext_ack struct, too.
It may still be worthwhile to have a mechanism for prioritizing certain
extack messages over another ones but it's clearly out of scope of this
patchset.
The patchset looks good to me. Just include the description you just
wrote in the commit message :-)
Thanks!
Jiri
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Johannes Berg @ 2018-09-19 9:44 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev
In-Reply-To: <20180919112829.647896cf@redhat.com>
On Wed, 2018-09-19 at 11:28 +0200, Jiri Benc wrote:
> > It might be possible to do this differently, in theory, but all the ways
> > I've tried to come up with so far made the code vastly more complex.
>
> Wouldn't still make sense to store the flag in the struct
> netlink_ext_ack, though?
Does it make sense to store a flag there that only has a single,
localized, user? I'd say no.
> The way the parameters are passed around in
> this patch looks ugly.
Yeah, it's not the best in some ways.
I considered having a cleared new extack on the stack in the outer-most
call (nla_parse/nla_validate), and then we can "set if not already set",
and at the end unconditionally copy/set to the real one... But then I
either need to duplicate that code in both, or pass another argument to
nla_validate_parse() anyway to indicate whether to do this or not (since
the inner calls to it shouldn't, since that would defeat the purpose),
or add another level of function call indirection?
I'm not really sure any of these are better ... and more complex, in
some ways, since we have to copy all the data around.
> And adding more users of the flag later (there
> may be other cases when we want the earlier messages to be preserved)
> would mean adding parameters all around, while the flag in the struct
> would be readily available.
I can't really think of any other users of such a thing?
johannes
^ permalink raw reply
* Re: [RFC] net;sched: Try to find idle cpu for RPS to handle packets
From: Kirill Tkhai @ 2018-09-19 15:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: Peter Zijlstra, David Miller, Daniel Borkmann, tom, netdev, LKML
In-Reply-To: <CANn89iJ1UnwLFv5+AwXgeb1BUhYg8UJYTJLtiipavJee+2SWxQ@mail.gmail.com>
On 19.09.2018 17:55, Eric Dumazet wrote:
> On Wed, Sep 19, 2018 at 5:29 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>
>> Many workloads have polling mode of work. The application
>> checks for incomming packets from time to time, but it also
>> has a work to do, when there is no packets. This RFC
>> tries to develop an idea to queue RPS packets on idle
>> CPU in the the L3 domain of the consumer, so backlog
>> processing of the packets and the application can execute
>> in parallel.
>>
>> We require this in case of network cards does not
>> have enough RX queues to cover all online CPUs (this seems
>> to be the most cards), and get_rps_cpu() actually chooses
>> remote cpu, and SMP interrupt is sent. Here we may try
>> our best, and to find idle CPU nearly the consumer's CPU.
>> Note, that in case of consumer works in poll mode and it
>> does not waits for incomming packets, its CPU will be not
>> idle, while CPU of a sleeping consumer may be idle. So,
>> not polling consumers will still be able to have skb
>> handled on its CPU.
>>
>> In case of network card has many queues, the device
>> interrupts will come on consumer's CPU, and this patch
>> won't try to find idle cpu for them.
>>
>> I've tried simple netperf test for this:
>> netserver -p 1234
>> netperf -L 127.0.0.1 -p 1234 -l 100
>>
>> Before:
>> 87380 16384 16384 100.00 60323.56
>> 87380 16384 16384 100.00 60388.46
>> 87380 16384 16384 100.00 60217.68
>> 87380 16384 16384 100.00 57995.41
>> 87380 16384 16384 100.00 60659.00
>>
>> After:
>> 87380 16384 16384 100.00 64569.09
>> 87380 16384 16384 100.00 64569.25
>> 87380 16384 16384 100.00 64691.63
>> 87380 16384 16384 100.00 64930.14
>> 87380 16384 16384 100.00 62670.15
>>
>> The difference between best runs is +7%,
>> the worst runs differ +8%.
>>
>> What do you think about following somehow in this way?
>
> Hi Kirill
>
> In my experience, scheduler has a poor view of softirq processing
> happening on various cpus.
> A cpu spending 90% of its cycles processing IRQ might be considered 'idle'
Yes, in case of there is softirq on top of irq_exit(), the cpu is not
considered as busy. But after MAX_SOFTIRQ_TIME (=2ms), ksoftirqd are
waken up to execute the work in process context, and the processor is
considered as !idle. 2ms is 2 timer ticks in case of HZ=1000. So, we
don't restart softirq in case of it was executed for more then 2ms.
The similar way, single net_rx_action() can't be executed longer
than 2ms.
Having 90% load in softirq (called on top of irq_exit()) should be
very unlikely situation, when there are too many interrupts with small
amount of work, which related softirq calls are doing for each of them.
I think it had be a problem even in plain napi case, since it would
worked not like expected.
But anyway. You worry, that during handling of next portion of skbs,
we find that previous portion of skbs already woken ksoftirqd, and
we don't see this cpu as idle? Yeah, then we'll try to change cpu,
and this is not what we want. We want to continue use the cpu, where
previous portion was handler. Hm, not so fast I'll answer, but certainly,
this may be handled somehow in more creative way.
> So please run a real workload (it is _very_ uncommon anyone set up RPS
> on lo interface !)
>
> Like 400 or more concurrent netperf -t TCP_RR on a 10Gbit NIC.
Yeah, it's just a simulation of a single irq nic. I'll try on something
more real hardware.
How do you execute such the tests? I don't see the appropriate parameter
of netperf. Does this mean just to start 400 copies of netperf? How is
to aggregate their results in this case?
> Thanks.
>
> PS: Idea of playing with L3 domains is interesting, I have personally
> tried various strategies in the past but none of them
> demonstrated a clear win.
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: phy: phylink: ensure the carrier is off when starting phylink
From: Russell King - ARM Linux @ 2018-09-19 10:07 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, andrew, f.fainelli, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180919093933.24411-2-antoine.tenart@bootlin.com>
On Wed, Sep 19, 2018 at 11:39:31AM +0200, Antoine Tenart wrote:
> Phylink made an assumption about the carrier state being down when
> calling phylink_start(). If this assumption isn't satisfied, the
> internal phylink state could misbehave and a net device could end up not
> being functional.
>
> This patch fixes this by explicitly calling netif_carrier_off() in
> phylink_start().
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
> ---
> drivers/net/phy/phylink.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 3ba5cf2a8a5f..1d01e0c625a5 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -901,6 +901,9 @@ void phylink_start(struct phylink *pl)
> phylink_an_mode_str(pl->link_an_mode),
> phy_modes(pl->link_config.interface));
>
> + /* Always set the carrier off */
> + netif_carrier_off(pl->netdev);
> +
> /* Apply the link configuration to the MAC when starting. This allows
> * a fixed-link to start with the correct parameters, and also
> * ensures that we set the appropriate advertisement for Serdes links.
> --
> 2.17.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: Bridge connectivity interruptions while devices join or leave the bridge
From: Ido Schimmel @ 2018-09-19 10:07 UTC (permalink / raw)
To: Johannes Wienke; +Cc: netdev
In-Reply-To: <7e7e9b1d-b6b5-b72f-efe6-52d700ad1ffc@techfak.uni-bielefeld.de>
On Wed, Sep 19, 2018 at 11:10:22AM +0200, Johannes Wienke wrote:
> Can someone explain what is happening here and why adding and removing
> devices to a bridge results in the connectivity issues? How to avoid
> this behavior? I'd be glad for any hint on that.
The MAC address of the bridge ('brtest' in your example) is inherited
from the bridge port with the "smallest" MAC address. Thus, when you
generate veth devices with random MACs and enslave them to the bridge,
you sometimes change the bridge's MAC address as well. And since the
bridge is the default gateway sometimes packets are sent to the wrong
MAC address.
You can avoid randomly changing the bridge's MAC by setting it
explicitly:
# ip link set dev brtest address <some_mac>
^ permalink raw reply
* [PATCH] net: sched: Use FIELD_SIZEOF directly instead of reimplementing its function
From: zhong jiang @ 2018-09-19 9:56 UTC (permalink / raw)
To: davem; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel
FIELD_SIZEOF is defined as a macro to calculate the specified vaule. Therefore,
We prefer to use the macro rather than calculating its vaule.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/sched/cls_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 4b8dd37..9aada2d 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -993,7 +993,7 @@ static int fl_init_mask_hashtable(struct fl_flow_mask *mask)
}
#define FL_KEY_MEMBER_OFFSET(member) offsetof(struct fl_flow_key, member)
-#define FL_KEY_MEMBER_SIZE(member) (sizeof(((struct fl_flow_key *) 0)->member))
+#define FL_KEY_MEMBER_SIZE(member) FIELD_SIZEOF(struct fl_flow_key, member)
#define FL_KEY_IS_MASKED(mask, member) \
memchr_inv(((char *)mask) + FL_KEY_MEMBER_OFFSET(member), \
--
1.7.12.4
^ permalink raw reply related
* Re: [RFC] net;sched: Try to find idle cpu for RPS to handle packets
From: Kirill Tkhai @ 2018-09-19 15:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Peter Zijlstra, David Miller, Daniel Borkmann, tom, netdev, LKML
In-Reply-To: <CANn89iK8X5cW3=YnNRrKo=BVCFJkJ0D22YY_eJFLyGCX+5SxsQ@mail.gmail.com>
On 19.09.2018 18:49, Eric Dumazet wrote:
> On Wed, Sep 19, 2018 at 8:41 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>
>> On 19.09.2018 17:55, Eric Dumazet wrote:
>>> On Wed, Sep 19, 2018 at 5:29 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>
>>>> Many workloads have polling mode of work. The application
>>>> checks for incomming packets from time to time, but it also
>>>> has a work to do, when there is no packets. This RFC
>>>> tries to develop an idea to queue RPS packets on idle
>>>> CPU in the the L3 domain of the consumer, so backlog
>>>> processing of the packets and the application can execute
>>>> in parallel.
>>>>
>>>> We require this in case of network cards does not
>>>> have enough RX queues to cover all online CPUs (this seems
>>>> to be the most cards), and get_rps_cpu() actually chooses
>>>> remote cpu, and SMP interrupt is sent. Here we may try
>>>> our best, and to find idle CPU nearly the consumer's CPU.
>>>> Note, that in case of consumer works in poll mode and it
>>>> does not waits for incomming packets, its CPU will be not
>>>> idle, while CPU of a sleeping consumer may be idle. So,
>>>> not polling consumers will still be able to have skb
>>>> handled on its CPU.
>>>>
>>>> In case of network card has many queues, the device
>>>> interrupts will come on consumer's CPU, and this patch
>>>> won't try to find idle cpu for them.
>>>>
>>>> I've tried simple netperf test for this:
>>>> netserver -p 1234
>>>> netperf -L 127.0.0.1 -p 1234 -l 100
>>>>
>>>> Before:
>>>> 87380 16384 16384 100.00 60323.56
>>>> 87380 16384 16384 100.00 60388.46
>>>> 87380 16384 16384 100.00 60217.68
>>>> 87380 16384 16384 100.00 57995.41
>>>> 87380 16384 16384 100.00 60659.00
>>>>
>>>> After:
>>>> 87380 16384 16384 100.00 64569.09
>>>> 87380 16384 16384 100.00 64569.25
>>>> 87380 16384 16384 100.00 64691.63
>>>> 87380 16384 16384 100.00 64930.14
>>>> 87380 16384 16384 100.00 62670.15
>>>>
>>>> The difference between best runs is +7%,
>>>> the worst runs differ +8%.
>>>>
>>>> What do you think about following somehow in this way?
>>>
>>> Hi Kirill
>>>
>>> In my experience, scheduler has a poor view of softirq processing
>>> happening on various cpus.
>>> A cpu spending 90% of its cycles processing IRQ might be considered 'idle'
>>
>> Yes, in case of there is softirq on top of irq_exit(), the cpu is not
>> considered as busy. But after MAX_SOFTIRQ_TIME (=2ms), ksoftirqd are
>> waken up to execute the work in process context, and the processor is
>> considered as !idle. 2ms is 2 timer ticks in case of HZ=1000. So, we
>> don't restart softirq in case of it was executed for more then 2ms.
>>
>
> That's the theory, but reality is very different unfortunately.
>
> If RFS/RPS is setup properly, we really do not hit MAX_SOFTIRQ_TIME condition
> unless in some synthetic benchmarks maybe.
>
>> The similar way, single net_rx_action() can't be executed longer
>> than 2ms.
>>
>> Having 90% load in softirq (called on top of irq_exit()) should be
>> very unlikely situation, when there are too many interrupts with small
>> amount of work, which related softirq calls are doing for each of them.
>> I think it had be a problem even in plain napi case, since it would
>> worked not like expected.
>>
>> But anyway. You worry, that during handling of next portion of skbs,
>> we find that previous portion of skbs already woken ksoftirqd, and
>> we don't see this cpu as idle? Yeah, then we'll try to change cpu,
>> and this is not what we want. We want to continue use the cpu, where
>> previous portion was handler. Hm, not so fast I'll answer, but certainly,
>> this may be handled somehow in more creative way.
>>
>>> So please run a real workload (it is _very_ uncommon anyone set up RPS
>>> on lo interface !)
>>>
>>> Like 400 or more concurrent netperf -t TCP_RR on a 10Gbit NIC.
>>
>> Yeah, it's just a simulation of a single irq nic. I'll try on something
>> more real hardware.
>
> Also my concern is that you might have results that are tied to a particular
> version of process scheduling, platform, workload...
>
> One month later, a small change in process scheduler,
> and very different results.
Maybe, but especially that function logic has not changed for a long time.
10 years at least. The only change is Peter adds idle core searching
functionality recently.
> This is why I believe this new feature must be controllable, via a new
> tunable (like RPS/RFS are controllable per rx queue)
>
>>
>> How do you execute such the tests? I don't see the appropriate parameter
>> of netperf. Does this mean just to start 400 copies of netperf? How is
>> to aggregate their results in this case?
>
> Yeah, there are various 'super_netperf' scripts available on the net
> (almost trivial to write anyway)
>
> ( I am attaching one of them)
Thanks.
> Thanks.
>>
>>> Thanks.
>>>
>>> PS: Idea of playing with L3 domains is interesting, I have personally
>>> tried various strategies in the past but none of them
>>> demonstrated a clear win.
>>
>> Thanks,
>> Kirill
^ permalink raw reply
* Re: [PATCH net-next] net: sun: fix return type of ndo_start_xmit function
From: Shannon Nelson @ 2018-09-19 16:01 UTC (permalink / raw)
To: YueHaibing, davem, alexander.h.duyck, yanjun.zhu,
jeffrey.t.kirsher, tklauser
Cc: linux-kernel, netdev
In-Reply-To: <20180919112132.26616-1-yuehaibing@huawei.com>
On 9/19/2018 4:21 AM, YueHaibing wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
> ---
> drivers/net/ethernet/sun/ldmvsw.c | 2 +-
> drivers/net/ethernet/sun/sunbmac.c | 3 ++-
> drivers/net/ethernet/sun/sunqe.c | 2 +-
> drivers/net/ethernet/sun/sunvnet.c | 2 +-
> drivers/net/ethernet/sun/sunvnet_common.c | 14 ++++++++------
> drivers/net/ethernet/sun/sunvnet_common.h | 7 ++++---
> 6 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/ldmvsw.c b/drivers/net/ethernet/sun/ldmvsw.c
> index d42f47f..644e42c 100644
> --- a/drivers/net/ethernet/sun/ldmvsw.c
> +++ b/drivers/net/ethernet/sun/ldmvsw.c
> @@ -113,7 +113,7 @@ static u16 vsw_select_queue(struct net_device *dev, struct sk_buff *skb,
> }
>
> /* Wrappers to common functions */
> -static int vsw_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t vsw_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> return sunvnet_start_xmit_common(skb, dev, vsw_tx_port_find);
> }
> diff --git a/drivers/net/ethernet/sun/sunbmac.c b/drivers/net/ethernet/sun/sunbmac.c
> index f047b27..720b7ac 100644
> --- a/drivers/net/ethernet/sun/sunbmac.c
> +++ b/drivers/net/ethernet/sun/sunbmac.c
> @@ -950,7 +950,8 @@ static void bigmac_tx_timeout(struct net_device *dev)
> }
>
> /* Put a packet on the wire. */
> -static int bigmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t
> +bigmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct bigmac *bp = netdev_priv(dev);
> int len, entry;
> diff --git a/drivers/net/ethernet/sun/sunqe.c b/drivers/net/ethernet/sun/sunqe.c
> index 7fe0d5e..1468fa0 100644
> --- a/drivers/net/ethernet/sun/sunqe.c
> +++ b/drivers/net/ethernet/sun/sunqe.c
> @@ -570,7 +570,7 @@ static void qe_tx_timeout(struct net_device *dev)
> }
>
> /* Get a packet queued to go onto the wire. */
> -static int qe_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t qe_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct sunqe *qep = netdev_priv(dev);
> struct sunqe_buffers *qbufs = qep->buffers;
> diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
> index 12539b3..5901728 100644
> --- a/drivers/net/ethernet/sun/sunvnet.c
> +++ b/drivers/net/ethernet/sun/sunvnet.c
> @@ -247,7 +247,7 @@ static u16 vnet_select_queue(struct net_device *dev, struct sk_buff *skb,
> }
>
> /* Wrappers to common functions */
> -static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> return sunvnet_start_xmit_common(skb, dev, vnet_tx_port_find);
> }
> diff --git a/drivers/net/ethernet/sun/sunvnet_common.c b/drivers/net/ethernet/sun/sunvnet_common.c
> index d8f4c3f..baa3088 100644
> --- a/drivers/net/ethernet/sun/sunvnet_common.c
> +++ b/drivers/net/ethernet/sun/sunvnet_common.c
> @@ -1216,9 +1216,10 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies)
> return skb;
> }
>
> -static int vnet_handle_offloads(struct vnet_port *port, struct sk_buff *skb,
> - struct vnet_port *(*vnet_tx_port)
> - (struct sk_buff *, struct net_device *))
> +static netdev_tx_t
> +vnet_handle_offloads(struct vnet_port *port, struct sk_buff *skb,
> + struct vnet_port *(*vnet_tx_port)
> + (struct sk_buff *, struct net_device *))
> {
> struct net_device *dev = VNET_PORT_TO_NET_DEVICE(port);
> struct vio_dring_state *dr = &port->vio.drings[VIO_DRIVER_TX_RING];
> @@ -1321,9 +1322,10 @@ static int vnet_handle_offloads(struct vnet_port *port, struct sk_buff *skb,
> return NETDEV_TX_OK;
> }
>
> -int sunvnet_start_xmit_common(struct sk_buff *skb, struct net_device *dev,
> - struct vnet_port *(*vnet_tx_port)
> - (struct sk_buff *, struct net_device *))
> +netdev_tx_t
> +sunvnet_start_xmit_common(struct sk_buff *skb, struct net_device *dev,
> + struct vnet_port *(*vnet_tx_port)
> + (struct sk_buff *, struct net_device *))
> {
> struct vnet_port *port = NULL;
> struct vio_dring_state *dr;
> diff --git a/drivers/net/ethernet/sun/sunvnet_common.h b/drivers/net/ethernet/sun/sunvnet_common.h
> index 1ea0b01..2b808d2 100644
> --- a/drivers/net/ethernet/sun/sunvnet_common.h
> +++ b/drivers/net/ethernet/sun/sunvnet_common.h
> @@ -136,9 +136,10 @@ struct vnet {
> void sunvnet_set_rx_mode_common(struct net_device *dev, struct vnet *vp);
> int sunvnet_set_mac_addr_common(struct net_device *dev, void *p);
> void sunvnet_tx_timeout_common(struct net_device *dev);
> -int sunvnet_start_xmit_common(struct sk_buff *skb, struct net_device *dev,
> - struct vnet_port *(*vnet_tx_port)
> - (struct sk_buff *, struct net_device *));
> +netdev_tx_t
> +sunvnet_start_xmit_common(struct sk_buff *skb, struct net_device *dev,
> + struct vnet_port *(*vnet_tx_port)
> + (struct sk_buff *, struct net_device *));
> #ifdef CONFIG_NET_POLL_CONTROLLER
> void sunvnet_poll_controller_common(struct net_device *dev, struct vnet *vp);
> #endif
>
^ permalink raw reply
* [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-19 10:23 UTC (permalink / raw)
To: davem, geoff, benh, paulus, mpe, kou.ishizaki, andrew, f.fainelli
Cc: linux-kernel, netdev, linuxppc-dev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 4 ++--
drivers/net/ethernet/toshiba/ps3_gelic_net.h | 2 +-
drivers/net/ethernet/toshiba/spider_net.c | 4 ++--
drivers/net/ethernet/toshiba/tc35815.c | 6 ++++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 88d74ae..75237c8 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -845,9 +845,9 @@ static int gelic_card_kick_txdma(struct gelic_card *card,
* @skb: packet to send out
* @netdev: interface device structure
*
- * returns 0 on success, <0 on failure
+ * returns NETDEV_TX_OK on success, NETDEV_TX_BUSY on failure
*/
-int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
+netdev_tx_t gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev)
{
struct gelic_card *card = netdev_card(netdev);
struct gelic_descr *descr;
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
index 003d045..fbbf9b5 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
@@ -370,7 +370,7 @@ static inline void udbg_shutdown_ps3gelic(void) {}
void gelic_card_down(struct gelic_card *card);
int gelic_net_open(struct net_device *netdev);
int gelic_net_stop(struct net_device *netdev);
-int gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
+netdev_tx_t gelic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
void gelic_net_set_multi(struct net_device *netdev);
void gelic_net_tx_timeout(struct net_device *netdev);
int gelic_net_setup_netdev(struct net_device *netdev, struct gelic_card *card);
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index d925b82..2341726 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -880,9 +880,9 @@
* @skb: packet to send out
* @netdev: interface device structure
*
- * returns 0 on success, !0 on failure
+ * returns NETDEV_TX_OK on success, NETDEV_TX_BUSY on failure
*/
-static int
+static netdev_tx_t
spider_net_xmit(struct sk_buff *skb, struct net_device *netdev)
{
int cnt;
diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c
index 7163a8d..6a71c2c 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -474,7 +474,8 @@ static void free_rxbuf_skb(struct pci_dev *hwdev, struct sk_buff *skb, dma_addr_
/* Index to functions, as function prototypes. */
static int tc35815_open(struct net_device *dev);
-static int tc35815_send_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t tc35815_send_packet(struct sk_buff *skb,
+ struct net_device *dev);
static irqreturn_t tc35815_interrupt(int irq, void *dev_id);
static int tc35815_rx(struct net_device *dev, int limit);
static int tc35815_poll(struct napi_struct *napi, int budget);
@@ -1248,7 +1249,8 @@ static void tc35815_tx_timeout(struct net_device *dev)
* invariant will hold if you make sure that the netif_*_queue()
* calls are done at the proper times.
*/
-static int tc35815_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+tc35815_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct tc35815_local *lp = netdev_priv(dev);
struct TxFD *txfd;
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox