Fixes: 83ba4645 ("net: add helpers checking if socket can be bound to nonlocal address")
Signed-off-by: NVincent Bernat <vincent@bernat.im>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

David Howells says:

====================
rxrpc: Development

Here are some patches that add some more tracepoints to AF_RXRPC and fix
some issues therein.  The most significant points are:

 (1) Display the call timeout information in /proc/net/rxrpc/calls.

 (2) Save the call's debug_id in the rxrpc_channel struct so that it can be
     used in traces after the rxrpc_call struct has been destroyed.

 (3) Increase the size of the kAFS Rx window from 32 to 63 to be about the
     same as the Auristor server.

 (4) Propose the terminal ACK for a client call after it has received all
     its data to be transmitted after a short interval so that it will get
     transmitted if not first superseded by a new call on the same channel.

 (5) Flush ACKs during the data reception if we detect that we've run out
     of data.[*]

 (6) Trace successful packet transmission and softirq to process context
     socket notification.

[*] Note that on a uncontended gigabit network, rxrpc runs in to trouble
    with ACK packets getting batched together (up to ~32 at a time)
    somewhere between the IP transmit queue on the client and the ethernet
    receive queue on the server.

    I can see the kernel afs filesystem client and Auristor userspace
    server stalling occasionally on a 512MB single read.  Sticking
    tracepoints in the network driver at either end seems to show that,
    although the ACK transmissions made by the client are reasonably spaced
    timewise, the received ACKs come in batches from the network card on
    the server.

    I'm not sure what, if anything, can be done about this.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For FW_PORT_ACTION_GET_PORT_INFO32 messages, the
u.info32.lstatus32_to_cbllen32 is 32-bit Big Endian.
We need to translate that to CPU Endian in order to
test F_FW_PORT_CMD_DCBXDIS32.
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Jiri Pirko says:

====================
net: sched: couple of adjustments/fixes
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These are no longer used outside of cls_api.c so make them static.
Move tcf_chain_flush() to avoid fwd declaration of tcf_chain_put().
Signed-off-by: NJiri Pirko <jiri@mellanox.com>

v1->v2:
- new patch
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Chains that only have action references serve as placeholders.
Until a non-action reference is created, user should not be aware
of the chain. Also he should not receive any notifications about it.
So send notifications for the new chain only in case the chain gets
the first non-action reference. Symmetrically to that, when
the last non-action reference is dropped, send the notification about
deleted chain.
Reported-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Acked-by: NCong Wang <xiyou.wangcong@gmail.com>

v1->v2:
- made __tcf_chain_{get,put}() static as suggested by Cong
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As mentioned by Cong and Jakub during the review process, it is a bit
odd to sometimes (act flow) create a new chain which would be
immediately a "zombie". So just rename it to "held_by_acts_only".
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Suggested-by: NCong Wang <xiyou.wangcong@gmail.com>
Suggested-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While cleaning the command queue, the value of the HEAD register is not
in the range of next_to_clean and next_to_use, meaning that this value
is invalid. This also means that there is a hardware error and the
hardware will trigger a reset soon. At this time we should return an
error code instead of 0, and HCLGE_STATE_CMD_DISABLE needs to be set to
prevent sending command again.

Fixes: 3ff50490 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean")
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Variable 'rds_ibdev' is being assigned but never used,
so can be removed.

fix this clang warning:
 net/rds/ib_send.c:762:24: warning: variable ‘rds_ibdev’ set but not used [-Wunused-but-set-variable]
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Variable 'rd_desc' is being assigned but never used,
so can be removed.

fix this clang warning:
net/strparser/strparser.c:411:20: warning: variable ‘rd_desc’ set but not used [-Wunused-but-set-variable]
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit ffc2b6ee ("ip_gre: fix IFLA_MTU ignored on NEWLINK")
variable t_hlen is assigned values that are never read,
hence they are redundant and can be removed.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes gcc '-Wunused-but-set-variable' warning:

net/ipv4/tcp_output.c: In function 'tcp_collapse_retrans':
net/ipv4/tcp_output.c:2700:6: warning:
 variable 'skb_size' set but not used [-Wunused-but-set-variable]
  int skb_size, next_skb_size;
      ^
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Wei Wang says:

====================
tcp: add 4 new stats

This patch series adds 3 RFC4898 stats:
1. tcpEStatsPerfHCDataOctetsOut
2. tcpEStatsPerfOctetsRetrans
3. tcpEStatsStackDSACKDups
and an addtional stat to record the number of data packet reordering
events seen:
4. tcp_reord_seen

Together with the existing stats, application can use them to measure
the retransmission rate in bytes, exclude spurious retransmissions
reflected by DSACK, and keep track of the reordering events on live
connections.
In particular the networks with different MTUs make bytes-based loss stats
more useful. Google servers have been using these stats for many years to
instrument transport and network performance.

Note: The first patch is a refactor to add a helper to calculate
opt_stats size in order to make later changes cleaner.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Introduce a new TCP stats to record the number of reordering events seen
and expose it in both tcp_info (TCP_INFO) and opt_stats
(SOF_TIMESTAMPING_OPT_STATS).
Application can use this stats to track the frequency of the reordering
events in addition to the existing reordering stats which tracks the
magnitude of the latest reordering event.

Note: this new stats tracks reordering events triggered by ACKs, which
could often be fewer than the actual number of packets being delivered
out-of-order.
Signed-off-by: NWei Wang <weiwan@google.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NNeal Cardwell <ncardwell@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Acked-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Introduce a new TCP stat to record the number of DSACK blocks received
(RFC4989 tcpEStatsStackDSACKDups) and expose it in both tcp_info
(TCP_INFO) and opt_stats (SOF_TIMESTAMPING_OPT_STATS).
Signed-off-by: NWei Wang <weiwan@google.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NNeal Cardwell <ncardwell@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Acked-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Introduce a new TCP stat to record the number of bytes retransmitted
(RFC4898 tcpEStatsPerfOctetsRetrans) and expose it in both tcp_info
(TCP_INFO) and opt_stats (SOF_TIMESTAMPING_OPT_STATS).
Signed-off-by: NWei Wang <weiwan@google.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NNeal Cardwell <ncardwell@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Acked-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Introduce a new TCP stat to record the number of bytes sent
(RFC4898 tcpEStatsPerfHCDataOctetsOut) and expose it in both tcp_info
(TCP_INFO) and opt_stats (SOF_TIMESTAMPING_OPT_STATS).
Signed-off-by: NWei Wang <weiwan@google.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NNeal Cardwell <ncardwell@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Acked-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is to refactor the calculation of the size of opt_stats to a helper
function to make the code cleaner and easier for later changes.
Suggested-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NWei Wang <weiwan@google.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Acked-by: NNeal Cardwell <ncardwell@google.com>
Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
Acked-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Petr Machata says:

====================
ipv4: Control SKB reprioritization after forwarding

After IPv4 packets are forwarded, the priority of the corresponding SKB
is updated according to the TOS field of IPv4 header. This overrides any
prioritization done earlier by e.g. an skbedit action or ingress-qos-map
defined at a vlan device.

Such overriding may not always be desirable. Even if the packet ends up
being routed, which implies this is an L3 network node, an administrator
may wish to preserve whatever prioritization was done earlier on in the
pipeline.

Therefore this patch set introduces a sysctl that controls this
behavior, net.ipv4.ip_forward_update_priority. It's value is 1 by
default to preserve the current behavior.

All of the above is implemented in patch #1.

Value changes prompt a new NETEVENT_IPV4_FWD_UPDATE_PRIORITY_UPDATE
notification, so that the drivers can hook up whatever logic may depend
on this value. That is implemented in patch #2.

In patches #3 and #4, mlxsw is adapted to recognize the sysctl. On
initialization, the RGCR register that handles router configuration is
set in accordance with the sysctl. The new notification is listened to
and RGCR is reconfigured as necessary.

In patches #5 to #7, a selftest is added to verify that mlxsw reflects
the sysctl value as necessary. The test is expressed in terms of the
recently-introduced ieee_setapp support, and works by observing how DSCP
value gets rewritten depending on packet priority. For this reason, the
test is added to the subdirectory drivers/net/mlxsw. Even though it's
not particularly specific to mlxsw, it's not suitable for running on
soft devices (which don't support the ieee_setapp et.al.).

Changes from v1 to v2:

- In patch #1, init sysctl_ip_fwd_update_priority to 1 instead of true.

Changes from RFC to v1:

- Fix wrong sysctl name in ip-sysctl.txt
- Add notifications
- Add mlxsw support
- Add self test
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Verify that with that sysctl turned off, DSCP prioritization and rewrite
works the same way as in qos_dscp_bridge test. However when the sysctl
is charged, there should be a reprioritization after routing stage,
which will be observed by a different DSCP rewrite on egress.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

dscp_capture_install() and dscp_capture_uninstall() are going to be
useful for a test added by a following patch, move them therefore to
lib.sh together with related helpers.

While doing so, change the rule preference from mere DSCP value to
DSCP+100 in order to support adding captures of packets with DSCP of 0.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function lldpad_wait() will be useful for a test added by a
following patch. Likewise would the "sleep 5" with its extensive
comment.

Therefore move lldpad_wait() to lib.sh in order to allow reuse. Rename
it to lldpad_app_wait_set() to recognize that what this is intended to
wait on are the pending APP sets.

For the sleeping, add a function lldpad_app_wait_del(). That will serve
to hold the related explanatory comment (which edit for clarity), and as
a token in the caller to identify the sites where this sort of waiting
takes place. That will serve when/if a better way to handle this
business is found.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This sysctl setting controls whether packet priority should be updated
after forwarding. Configure RGCR.usp accordingly so that the device is
in sync with the kernel handling.

Note that RGCR doesn't allow changing arbitrary parameters
mid-operation, however "usp" is exempt and can be reconfigured.

Also react to NETEVENT_IPV4_FWD_UPDATE_PRIORITY_UPDATE notifications
that signify change in this configuration.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The boilerplate to schedule NETEVENT_IPV4_MPATH_HASH_UPDATE and
NETEVENT_IPV6_MPATH_HASH_UPDATE handling is almost equivalent to that of
NETEVENT_IPV4_FWD_UPDATE_PRIORITY_UPDATE that's coming in the next
patch. The only difference is which actual worker function should be
called. Extract this boilerplate into a named function in order to allow
reuse.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Drivers may make offloading decision based on whether
ip_forward_update_priority is enabled or not. Therefore distribute
netevent notifications to give them a chance to react to a change.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After IPv4 packets are forwarded, the priority of the corresponding SKB
is updated according to the TOS field of IPv4 header. This overrides any
prioritization done earlier by e.g. an skbedit action or ingress-qos-map
defined at a vlan device.

Such overriding may not always be desirable. Even if the packet ends up
being routed, which implies this is an L3 network node, an administrator
may wish to preserve whatever prioritization was done earlier on in the
pipeline.

Therefore introduce a sysctl that controls this behavior. Keep the
default value at 1 to maintain backward-compatible behavior.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The construction "net->ipv4.sysctl_ip_nonlocal_bind || inet->freebind
|| inet->transparent" is present three times and its IPv6 counterpart
is also present three times. We introduce two small helpers to
characterize these tests uniformly.
Signed-off-by: NVincent Bernat <vincent@bernat.im>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Neterion was standalone for several years, then acquired by Exar and
shutdown in 11 months without ever making any new Exar branded adapters.
Users would probably think of them as Neterion and not Exar (as there
have been no follow-on adapters and the vast majority ever sold were
under the Neterion name).

6c541b45 ("net: ethernet: Sort Kconfig sourcing alphabetically")
sorted Kconfig sourcing based on directory names, but in a couple cases,
the menu item text is quite different from the directory name and is not
sorted correctly:

  drivers/net/ethernet/neterion/Kconfig    => "Exar devices"

To address that and clear up any confusion about the name, "Exar" was
changed to "Neterion (Exar)" and the relevant entries in the Makefile
and Kconfig were reordered to match the alphabetical organization.
Inspired-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJon Mason <jdmason@kudzu.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Kmemdup is better than kmalloc+memcpy. So replace them.
Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Variables 'tn' and 'oport'  are being assigned but are never used hence
they are redundant and can be removed.

Cleans up clang warnings:
warning: variable 'oport' set but not used [-Wunused-but-set-variable]
warning: variable 'tn' set but not used [-Wunused-but-set-variable]
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NYing Xue <ying.xue@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Suresh Reddy says:

====================
be2net: patch-set

v1->v2 : Modified the subject line and commit log.

Please consider applying these two patches to net-next.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch handles a TX-timeout as follows:

1) This patch gathers and prints the following info that can
   help in diagnosing the cause of a TX-timeout.
   a) TX queue and completion queue entries.
   b) SKB and TCP/UDP header details.

2) For Lancer NICs (TX-timeout recovery is not supported for
   BE3/Skyhawk-R NICs), it recovers from the TX timeout as follows:

   a) On a TX-timeout, driver sets the PHYSDEV_CONTROL_FW_RESET_MASK
      bit in the PHYSDEV_CONTROL register. Lancer firmware goes into
      an error state and indicates this back to the driver via a bit
      in a doorbell register.
   b) Driver detects this and calls be_err_recover(). DMA is disabled,
      all pending TX skbs are unmapped and freed (be_close()). All rings
      are destroyed (be_clear()).
   c) The driver waits for the FW to re-initialize and re-creates all
      rings along with other data structs (be_resume())
Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a potential execution path in which variable *err* is returned
without being properly initialized previously.

Fix this by initializing variable *err* to 0.

Addresses-Coverity-ID: 1472116 ("Uninitialized scalar variable")
Fixes: 0ec13877 ("net/mlx5e: Gather all XDP pre-requisite checks in a single function")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: NTariq Toukan <tariqt@mellanox.com>
Acked-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes the following sparse warning:

drivers/net/ethernet/qlogic/qed/qed_cxt.c:1534:6: warning: symbol 'qed_cm_init_pf' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:233:4: warning: symbol 'qed_init_qm_get_num_tcs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:238:5: warning: symbol 'qed_init_qm_get_num_vfs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:246:5: warning: symbol 'qed_init_qm_get_num_pf_rls' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:264:5: warning: symbol 'qed_init_qm_get_num_vports' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:276:5: warning: symbol 'qed_init_qm_get_num_pqs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_mcp.c:573:5: warning: symbol 'qed_mcp_nvm_wr_cmd' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_mcp.c:3012:1: warning: symbol '__qed_mcp_resc_lock' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dcbx.c:870:6: warning: symbol 'qed_dcbx_aen' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_debug.c:7841:5: warning: symbol 'qed_dbg_nvm_image_length' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_debug.c:7857:5: warning: symbol 'qed_dbg_nvm_image' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:675:6: warning: symbol '_qed_iov_pf_sanity_check' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:690:6: warning: symbol 'qed_iov_pf_sanity_check' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:3982:6: warning: symbol 'qed_iov_pf_get_pending_events' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_vf.c:172:5: warning: symbol '_qed_vf_pf_release' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:137:5: warning: symbol 'qed_rdma_get_sb_id' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:709:5: warning: symbol 'qed_rdma_stop' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_ll2.c:161:6: warning: symbol 'qed_ll2b_complete_rx_packet' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_roce.c:160:6: warning: symbol 'qed_roce_free_cid_pair' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:380:12: warning: symbol 'iwarp_state_names' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:946:1: warning: symbol 'qed_iwarp_parse_private_data' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:971:1: warning: symbol 'qed_iwarp_mpa_reply_arrived' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2504:1: warning: symbol 'qed_iwarp_ll2_slowpath' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2806:6: warning: symbol 'qed_iwarp_qp_in_error' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2827:6: warning: symbol 'qed_iwarp_exception_received' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2958:1: warning: symbol 'qed_iwarp_connect_complete' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iscsi.c:876:6: warning: symbol 'qed_iscsi_free_connection' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Acked-by: NDenis Bolotin <Denis.Bolotin@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes the IPv6 dependency from RDS.
Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, rds_ib_conn_alloc() calls rds_ib_recv_alloc_caches()
without passing along the gfp_t flag.  But rds_ib_recv_alloc_caches()
and rds_ib_recv_alloc_cache() should take a gfp_t parameter so that
rds_ib_recv_alloc_cache() can call alloc_percpu_gfp() using the
correct flag instead of calling alloc_percpu().
Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Replace ugly macroses on functions.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Immediately flush any outstanding ACK on entry to rxrpc_recvmsg_data() -
which transfers data to the target buffers - if we previously had an Rx
underrun (ie. we returned -EAGAIN because we ran out of received data).
This lets the server know what we've managed to receive something.

Also flush any outstanding ACK after calling the function if it hit -EAGAIN
to let the server know we processed some data.

It might be better to send more ACKs, possibly on a time-based scheme, but
that needs some more consideration.

With this and some additional AFS patches, it is possible to get large
unencrypted O_DIRECT reads to be almost as fast as NFS over TCP.  It looks
like it might be theoretically possible to improve performance yet more for
a server running a single operation as investigation of packet timestamps
indicates that the server keeps stalling.

The issue appears to be that rxrpc runs in to trouble with ACK packets
getting batched together (up to ~32 at a time) somewhere between the IP
transmit queue on the client and the ethernet receive queue on the server.

However, this case isn't too much of a worry as even a lightly loaded
server should be receiving sufficient packet flux to flush the ACK packets
to the UDP socket.
Signed-off-by: NDavid Howells <dhowells@redhat.com>

The final ACK that closes out an rxrpc call needs to be transmitted by the
client unless we're going to follow up with a DATA packet for a new call on
the same channel (which implicitly ACK's the previous call, thereby saving
an ACK).

Currently, we don't do that, so if no follow on call is immediately
forthcoming, the server will resend the last DATA packet - at which point
rxrpc_conn_retransmit_call() will be triggered and will (re)send the final
ACK.  But the server has to hold on to the last packet until the ACK is
received, thereby holding up its resources.

Fix the client side to propose a delayed final ACK, to be transmitted after
a short delay, assuming the call isn't superseded by a new one.
Signed-off-by: NDavid Howells <dhowells@redhat.com>