- 17 Jul, 2014 36 commits
-
-
David S. Miller authored
Anish Bhatt says: ==================== cxgb4i: Add ipv6 support The following patchset add ipv6 support for the cxgb4i(iscsi) driver. Patch 1 moves a define from the iw_cxgb4 to cxgb4 to prevent code duplication, as it is used by cxgb4i and iw_cxgb4 both. Patch 2 exports symbols needed by cxgb4i for ipv6 support from cxgb4. Patch 3 & 4 deal with actual ipv6 code in libcxgbi/cxgb4i. Submitting to net-next as changes were needed in cxgb4/iw_cxgb4, and submitting to scsi separately would break compilation, cc-ing scsi & rdma. v2 : Cleanup macro that prints ip addresses by using %pIS in patch 3 ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Anish Bhatt authored
Signed-off-by:
Anish Bhatt <anish@chelsio.com> Signed-off-by:
Karen Xie <kxie@chelsio.com> Signed-off-by:
Manoj Malviya <manojmalviya@chelsio.com> Signed-off-by:
-
Anish Bhatt authored
Signed-off-by:
-
Anish Bhatt authored
Signed-off-by:
-
Anish Bhatt authored
This define is used by cxgb4i and iw_cxgb4, moving to avoid code duplication Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
-
Jianhua Xie authored
Document the Layer 2 hash factors with packet type ID field. CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: David S. Miller <davem@davemloft.net> CC: Pan Jiafei <Jiafei.Pan@freescale.com> Signed-off-by:
Jianhua Xie <jianhua.xie@freescale.com> Signed-off-by:
-
Jianhua Xie authored
Current L2 hash helper calculates destination eth addr and source ether addr as L2 hash factors. This patch is adding packet type ID field into L2 hash factors. While one of BOND_XMIT_POLICY_LAYER2 or BOND_XMIT_POLICY_{LAYER|ENCAP}23 is applied, for the 2nd level hash, enhanced hash method can help to distribute different types of packets like IPv4/IPv6 packets to different slave devices. CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: David S. Miller <davem@davemloft.net> CC: Pan Jiafei <Jiafei.Pan@freescale.com> Acked-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Anish Bhatt authored
v2: fixed issue with checking return of dcbnl_rtnl_ops->getapp() Signed-off-by:
-
Cong Wang authored
Like other places, we need to cancel the nest attribute after we start. Fortunately the netlink message will not be sent on failure, so it's not a big problem at all. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Cong Wang <cwang@twopensource.com> Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-nextDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2014-07-16 This series contains updates to i40e only. Neerav adds support to get the port MAC address from firmware and adds support to the ndo_get_phys_port_id() callback to provide port specific unique ids to the netdev layer. Jakub Kicinski provides 2 fixes, first fixes i40e to never generate a software time stamp if the hardware time stamp is provided. Second fixes a race condition on queueing skb for hardware time by using a simple bit lock to avoid race conditions and leaking skbs when multiple transmit rings try to claim time stamping. Paul does some general cleanup of the driver to remove unneeded spaces, comments that are no longer valid, and break that will never get touched. Jacob Keller adds a verbose warning message when the incorrect PF attempts to control timestamping for a port to which it was not assigned. The primary intent of this message is to help debugging the reason why the SIOCSHWSTAMP ioctl has failed and to help narrow the cause of the issue. ==================== Signed-off-by: -
stephen hemminger authored
Generic netlink tables can be const. Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Mahesh Bandewar authored
In TLB mode if tlb_dynamic_lb is NOT set, slaves from the bond group are selected based on the hash distribution. This does not exclude dead links which are part of the bond. Also if there is a temporary link event which brings down the interface, packets hashed on that interface would be dropped too. This patch fixes these issues and distributes flows across the UP links only. Also the array construction of links which are capable of sending packets happen in the control path leaving only link-selection during the data-path. One possible side effect of this is - at a link event; all flows will be shuffled to get good distribution. But impact of this should be minimum with the assumption that a member or members of the bond group are not available is a very temporary situation. Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
-
David S. Miller authored
Grygorii Strashko says: ==================== net: davinci_mdio: reuse for keystone2 arch The similar MDIO HW blocks is used by keystone 2 SoCs as in Davinci SoCs: - one in Gigabit Ethernet (GbE) Switch Subsystem See http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf - one in 10 Gigabit Ethernet Subsystem See http://www.ti.com/lit/ug/spruhj5/spruhj5.pdf Hence, reuse Davinci MDIO driver for Keystone 2 and enable TI networking for Keystone 2 devices. Also, as part of this series, enable PHY's creation from DT, because Keystone 2 supports DT boot mode only. Changes in v2: - review comments applied. Keystone 2 compatibility string changed to "ti,keystone_mdio". ==================== Signed-off-by:
-
Grygorii Strashko authored
This patch allows to create PHYs from DT in case if they are explicitly defined. The of_mdiobus_register() is used for such purposes. For backward compatibility, call of_mdiobus_register() only in case if at least one PHY's child is defined in DT, otherwise rollback to mdiobus_register(). Reviewed-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Grygorii Strashko authored
The similar MDIO HW blocks is used by keystone 2 SoCs as in Davinci SoCs: - one in Gigabit Ethernet (GbE) Switch Subsystem See http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf - one in 10 Gigabit Ethernet Subsystem See http://www.ti.com/lit/ug/spruhj5/spruhj5.pdf Hence, reuse Davinci MDIO driver for Keystone 2 and enable TI networking for Keystone 2 devices Reviewed-by:
-
Jeff Layton authored
sparse is throwing warnings when building sunrpc modules due to some endianness shenanigans in ipv6.h. Specifically: CHECK net/sunrpc/addr.c include/net/ipv6.h:573:17: warning: restricted __be64 degrades to integer include/net/ipv6.h:577:34: warning: restricted __be32 degrades to integer include/net/ipv6.h:573:17: warning: restricted __be64 degrades to integer include/net/ipv6.h:577:34: warning: restricted __be32 degrades to integer Sprinkle some endianness fixups to silence them. These should all get fixed up at compile time, so I don't think this will add any extra work to be done at runtime. Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
David S. Miller authored
David Held says: ==================== udp: Fix multicast performance issues. Fix performance issues with listening to many different multicast sockets on different addresses with the same port. Instead of always using hash1, fall back to hash2 lookup when hash1 lookup is long. Patch 1 is a general cleanup and simplification which also makes the main implementation in Patch 2 simpler. Eric's recent change 63c6f81c avoided this being an issue in early demux. This makes it work for regular delivery as well. v1->v2 - updated hash collision detection v2->v3 - avoid flushing under lock unnecessarily at ARRAY_SIZE boundary ==================== Signed-off-by:
-
David Held authored
Many multicast sources can have the same port which can result in a very large list when hashing by port only. Hash by address and port instead if this is the case. This makes multicast more similar to unicast. On a 24-core machine receiving from 500 multicast sockets on the same port, before this patch 80% of system CPU was used up by spin locking and only ~25% of packets were successfully delivered. With this patch, all packets are delivered and kernel overhead is ~8% system CPU on spinlocks. Signed-off-by:
David Held <drheld@google.com> Signed-off-by:
-
David Held authored
Switch to using sk_nulls_for_each which shortens the code and makes it easier to update. Signed-off-by:
-
David S. Miller authored
Amir Vadai says: ==================== Mellanox driver update Jul-16-2014 This patchset contains some bug fixes related to MCG table management (flow steering) in Mellanox NIC. Fixes were applied and tested over commit 0854a7f1 ("Merge branch 'amd811e-cleanups'"). ==================== Signed-off-by:
-
Saeed Mahameed authored
In B0 steering mode if promiscuous QP asks to be detached from MCG entry, and it is the only one in this entry then the entry will never be deleted. This is a wrong behavior since we don't want to keep those entries after the promiscuous QP becomes non-promiscuous. Therefore remove steering entry containing only promiscuous QP. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
In current situation host is adding the promiscuous QP to all steering entries and the default entry as well. In this case when having PV and SR-IOV on the same setup bridge will receive all traffic that is targeted to the other VMs. This is bad. Solution: In SR-IOV mode host can add promiscuous QP to default entry only. The above problem and fix are relevant for B0 steering mode only. Signed-off-by:
-
Alexander Guller authored
In B0 steering mode when adding QPs to the default MCG entry need to check that maximal number of QPs per MCG entry was not exceeded. Signed-off-by:
Alexander Guller <alexg@mellanox.com> Reviewed-by:
Aviad Yehezkel <aviadye@mellanox.co.il> Signed-off-by:
-
Dotan Barak authored
To make sure that the array index isn't used in the code with negative value, we stop using the for loop integer iterator outside of it. >From now on use members count to swap the last QP with removed one. Fix also the second occurrence of this flow in mlx4_qp_detach_common(). In mlx4_qp_detach_common() use members_count instead of loop iterator outside of the for loop. Signed-off-by:
Dotan Barak <dotanb@dev.mellanox.co.il> Reviewed-by:
Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by:
-
Yevgeny Petrilin authored
When removing multicast address in B0 steering mode there is a bug in cases where there is a single QP registered for the address, and this QP is also promiscuous. In such cases the entry wouldn't be deleted from the SW structure representing all Ethernet MCG entries, but would be removed in HW. This way when driver goes to remove it from SW and HW structures the HW deletion fails. Moreover the same index could later be used for registering different address, which can be Infiniband. Signed-off-by:
-
Varka Bhadram authored
This patch removes the bool variable 'pass'. If the swith case exist return true or return false. Signed-off-by:
Varka Bhadram <varkab@cdac.in> Signed-off-by:
-
Alexander Duyck authored
This change cleans up ndo_dflt_fdb_del to drop the ENOTSUPP return value since that isn't actually returned anywhere in the code. As a result we are able to drop a few lines by just defaulting this to -EINVAL. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
françois romieu authored
Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: multicast and internal users to new send functions We move the remaining data transmit users: multicast, name table distributor, and link internal protocols to use the new data transmission framework introduced in a previous commit series ("tipc: new unicast transmission code"). Finally, we remove the code obsoleted by the new functions. v2: - Fixed a braindead, but harmless return sequence in commit #3, as reported by David Miller. - Rebased series to 3.16.0-rc5+ ==================== Signed-off-by: -
Jon Paul Maloy authored
When we run broadcast packets over dual bearers/interfaces, the current transmission code is flipping bearers between each sent packet, with the purpose of leveraging the double bandwidth available. The receiving bclink is resequencing the packets if needed, so all messages are delivered upwards from the broadcast link in the correct order, even if they may arrive in concurrent interrupts. However, at the moment of delivery upwards to the socket, we release all spinlocks (bclink_lock, node_lock), so it is still possible that arriving messages bypass each other before they reach the socket queue. We fix this by applying the same technique we are using for unicast traffic. We use a link selector (i.e., the last bit of sending port number) to ensure that messages from the same sender socket always are sent over the same bearer. This guarantees sequential delivery between socket pairs, which is sufficient to satisfy the protocol spec, as well as all known user requirements. Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Reviewed-by:
Erik Hugne <erik.hugne@ericsson.com> Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Jon Paul Maloy authored
After the previous commit, we can now give the functions with temporary names, such as tipc_link_xmit2(), tipc_msg_build2() etc., their proper names. There are no functional changes in this commit. Signed-off-by:
-
Jon Paul Maloy authored
We can now remove a number of functions which have become obsolete and unreferenced through this commit series. There are no functional changes in this commit. Signed-off-by:
-
Jon Paul Maloy authored
In this commit, we convert the socket multicast send function to directly call the new multicast/broadcast function (tipc_bclink_xmit2()) introduced in the previous commit. We do this instead of letting the call go via the now obsolete tipc_port_mcast_xmit(), hence saving a call level and some code complexity. We also remove the initial destination lookup at the message sending side, and replace that with an unconditional lookup at the receiving side, including on the sending node itself. This makes the destination lookup and message transfer more uniform than before. Signed-off-by:
-
Jon Paul Maloy authored
We add a new broadcast link transmit function in bclink.c and a new receive function in socket.c. The purpose is to move the branching between external and internal destination down to the link layer, just as we have done with unicast in earlier commits. We also make use of the new link-independent fragmentation support that was introduced in an earlier commit series. This gives a shorter and simpler code path, and makes it possible to obtain copy-free buffer delivery to all node local destination sockets. The new transmission code is added in parallel with the existing one, and will be used by the socket multicast send function in the next commit in this series. Signed-off-by:
-
Jon Paul Maloy authored
We convert the link internal users (changeover protocol, broadcast synchronization) to use the new packet send function. Signed-off-by:
-
Jon Paul Maloy authored
In a previous commit series ("tipc: new unicast transmission code") we introduced a new message sending function, tipc_link_xmit2(), and moved the unicast data users over to use that function. We now let the internal name table distributor do the same. The interaction between the name distributor and the node/link layer also becomes significantly simpler, so we can eliminate the function tipc_link_names_xmit(). Signed-off-by:
-
- 16 Jul, 2014 4 commits
-
-
Christoph Schulz authored
Commit d762d038 resets the counter holding the next sequence number for multilink PPP fragments to zero whenever the SC_MULTILINK flag is set. However, this counter only exists if CONFIG_PPP_MULTILINK is defined. Consequently, the new code has to be enclosed within #ifdef CONFIG_PPP_MULTILINK ... #endif. Signed-off-by:
Christoph Schulz <develop@kristov.de> Signed-off-by:
-
David S. Miller authored
Daniel Borkmann says: ==================== SCTP updates This set improves the SCTP socket API to be more in line with RFC6458, Geir and myself have finalized it eventually. While at it, the first patch also fixes two possible information leaks that should go to net tree as well (therefore the change is already here in net-next via a merge of the 'net' tree -DaveM). For more details, I refer you to the patches themselves. Thanks a lot. v1 -> v2: - Added 6th patch to deprecate SCTP_SNDRCV, rest unchanged ==================== CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
Veaceslav Falico <vfalico@gmail.com> Signed-off-by:
-
Daniel Borkmann authored
With support of SCTP_SNDINFO/SCTP_RCVINFO as described in RFC6458, 5.3.4/5.3.5, we can now deprecate SCTP_SNDRCV. The RFC already declares it as deprecated: This structure mixes the send and receive path. SCTP_SNDINFO (described in Section 5.3.4) and SCTP_RCVINFO (described in Section 5.3.5) split this information. These structures should be used, when possible, since SCTP_SNDRCV is deprecated. So whenever a user tries to subscribe to sctp_data_io_event via setsockopt(2) which triggers inclusion of SCTP_SNDRCV cmsg_type, issue a warning in the log. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Geir Ola Vaagland authored
This patch implements section 8.1.31. of RFC6458, which adds support for setting/retrieving SCTP_DEFAULT_SNDINFO: Applications that wish to use the sendto() system call may wish to specify a default set of parameters that would normally be supplied through the inclusion of ancillary data. This socket option allows such an application to set the default sctp_sndinfo structure. The application that wishes to use this socket option simply passes the sctp_sndinfo structure (defined in Section 5.3.4) to this call. The input parameters accepted by this call include snd_sid, snd_flags, snd_ppid, and snd_context. The snd_flags parameter is composed of a bitwise OR of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL. The snd_assoc_id field specifies the association to which to apply the parameters. For a one-to-many style socket, any of the predefined constants are also allowed in this field. The field is ignored for one-to-one style sockets. Joint work with Daniel Borkmann. Signed-off-by:
Geir Ola Vaagland <geirola@gmail.com> Signed-off-by:
-
