- 11 Nov, 2018 37 commits
-
-
Eric Dumazet authored
Applications using MSG_EOR are giving a strong hint to TCP stack : Subsequent sendmsg() can not append more bytes to skbs having the EOR mark. Do not try to TSO defer suchs skbs, there is really no hope. Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yafang Shao authored
Bitwise operation is a little faster. So I replace after() with using the flag FLAG_SND_UNA_ADVANCED as it is already set before. In addtion, there's another similar improvement in tcp_cwnd_reduction(). Cc: Joe Perches <joe@perches.com> Suggested-by:
Yafang Shao <laoar.shao@gmail.com> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== net: dsa: mv88e6xxx: Support more SERDES interfacxes Currently the SERDES interfaces for ports 9 and 10 on the mv88e6390x are supported, allowing upto 10G. However, when unused, these SERDES interfaces can be used by some of the lower ports for 1000Base-X. The tricky bit here is ordering. The SERDES have to become free from ports 9 or 10 before they can be used with lower ports. Normally, this would happen only when these ports would be configured up, which is too late. So at probe time, defaulting ports 9 and 10 to 1000BaseX frees them for use with lower ports. If they are actually needed, they will be taken back when port 9 and 10 goes up. ==================== Signed-off-by: -
Andrew Lunn authored
The 6390X family has 8 SERDES interfaces. When ports 9 and 10 are not using all their SERDES interfaces, the unused ones can be assigned to ports 2-8. Add support for interrupts from SERDES interfaces connected to these lower ports. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
The 6390X family has 8 SERDES interfaces. This allows ports 9 and 10 to support up to 10Gbps using 4 SERDES interfaces. However, when lower speeds are used, which need fewer SERDES interfaces, the unused SERDES interfaces can be used by ports 2-8. The hardware defaults to ports 9 and 10 having all 4 SERDES interfaces assigned to them. This only gets changed when the interface is configured after what the SFP supports has been determined, or the 10G PHY completes auto-neg. For hardware designs which limit ports 9 and 10 to one or two SERDES interfaces, and place SFPs on the lower interfaces, this is too late. Those ports with SFP should not wait until ports 9/10 are up in order to get access to the SERDES interface. So change the default configuration when the driver is initialised. Configure ports 9 and 10 to 1000BaseX, so they use a single SERDES interface, freeing up the others. They can steal them back if they need them. Signed-off-by:
-
Andrew Lunn authored
The X family variants support additional ports modes, for 10G operation, which the non-X variants don't have. Add a port_set_cmode() for non-X variants to enforce this. Signed-off-by:
-
Andrew Lunn authored
Move .port_set_cmode next to .port_get_cmode. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== net: phy: convert advertise and supported to linkmode This is the last part in converting phylib to make use of a linux bitmap, not a u32, to represent links modes. This will allow support for PHYs > 1Gbps, which need to use link modes represented by a bit > 32. A number of MAC and PHY drivers need changes to support this. However the previous two patchesets reduced the number somewhat, the helpers which were introduced have been modified instead of the actual drivers. The follow on patches then make use of the extra bits, adding support for more link modes. Given how invasive this change is, i expect the build is broken for some architectures i did not test. I will fixup the breakage as fast as i can. ==================== Signed-off-by: -
Andrew Lunn authored
Now that 2.5G and 5G can be represented in phydev->advertising and phydev->lp_advertising, add these two links modes as possible resolutions to auto negotiation. Signed-off-by:
-
Andrew Lunn authored
Now that PHYs and MAC can support more than 32 bit masks, add link modes which are > 31 to the PHY settings table. Signed-off-by:
-
Andrew Lunn authored
Add missing markup for function parameters Signed-off-by:
-
Andrew Lunn authored
Convert phy drivers to report the link partner advertised modes using a linkmode bitmap. This allows them to report the higher speeds which don't fit in a u32. Signed-off-by:
-
Andrew Lunn authored
There are a few MAC/PHYs combinations which now support > 1Gbps. These may need to make use of link modes with bits > 31. Thus their supported PHY features or advertised features cannot be implemented using the current bitmap in a u32. Convert to using a linkmode bitmap, which can support all the currently devices link modes, and is future proof as more modes are added. Signed-off-by:
-
Heiner Kallweit authored
Both states aren't used. Most likely they result from an idea that never materialized. So remove them. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
yupeng authored
The snmp_counter.rst explains the meanings of snmp counters. It also provides a set of experiments (only 1 for this initial patch), combines the experiments' resutls and the snmp counters' meanings. This is an initial path, only explains a part of IP/ICMP counters and provide a simple ping test. Signed-off-by:
yupeng <yupeng0921@gmail.com> Signed-off-by:
-
LUU Duc Canh authored
Currently, the broadcast retransmission algorithm is using the 'prev_retr' field in struct tipc_link to time stamp the latest broadcast retransmission occasion. This helps to restrict retransmission of individual broadcast packets to max once per 10 milliseconds, even though all other criteria for retransmission are met. We now move this time stamp to the control block of each individual packet, and remove other limiting criteria. This simplifies the retransmission algorithm, and eliminates any risk of logical errors in selecting which packets can be retransmitted. Acked-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
LUU Duc Canh <canh.d.luu@dektech.com.au> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== net: sched: indirect tc block cb registration John says: This patchset introduces an alternative to egdev offload by allowing a driver to register for block updates when an external device (e.g. tunnel netdev) is bound to a TC block. Drivers can track new netdevs or register to existing ones to receive information on such events. Based on this, they may register for block offload rules using already existing functions. The patchset also implements this new indirect block registration in the NFP driver to allow the offloading of tunnel rules. The use of egdev offload (which is currently only used for tunnel offload) is subsequently removed. RFC v2 -> PATCH - removed embedded tracking function from indir block register (now up to driver to clean up after itself) - refactored NFP code due to recent submissions - removed priv list clean function in NFP (list should be cleared by indirect block unregisters) RFC v1->v2: - free allocated owner struct in block_owner_clean function - add geneve type helper function - move test stub in NFP (v1 patch 2) to full tunnel offload implementation via indirect blocks (v2 patches 3-8) ==================== Signed-off-by: -
John Hurley authored
Recent changes to NFP mean that stats updates from fw to driver no longer require a flow lookup and (because egdev offload has been removed) the ingress netdev for a lookup is now always known. Remove obsolete code in a flow lookup that matches on host context and that allows for a netdev to be NULL. Signed-off-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
John Hurley authored
Previously, only tunnel decap rules required egdev registration for offload in NFP. These are now supported via indirect TC block callbacks. Remove the egdev code from NFP. Signed-off-by:
-
John Hurley authored
Previously, TC block tunnel decap rules were only offloaded when a callback was triggered through registration of the rules egress device. This meant that the driver had no access to the ingress netdev and so could not verify it was the same tunnel type that the rule implied. Register tunnel devices for indirect TC block offloads in NFP, giving access to new rules based on the ingress device rather than egress. Use this to verify the netdev type of VXLAN and Geneve based rules and offload the rules to HW if applicable. Tunnel registration is done via a netdev notifier. On notifier registration, this is triggered for already existing netdevs. This means that NFP can register for offloads from devices that exist before it is loaded (filter rules will be replayed from the TC core). Similarly, on notifier unregister, a call is triggered for each currently active netdev. This allows the driver to unregister any indirect block callbacks that may still be active. Signed-off-by:
-
John Hurley authored
Both the actions and tunnel_conf files contain local functions that check the type of an input netdev. In preparation for re-use with tunnel offload via indirect blocks, move these to static inline functions in a header file. Signed-off-by:
-
John Hurley authored
Previously the offload functions in NFP assumed that the ingress (or egress) netdev passed to them was an nfp repr. Modify the driver to permit the passing of non repr netdevs as the ingress device for an offload rule candidate. This may include devices such as tunnels. The driver should then base its offload decision on a combination of ingress device and egress port for a rule. Signed-off-by:
-
John Hurley authored
Currently drivers can register to receive TC block bind/unbind callbacks by implementing the setup_tc ndo in any of their given netdevs. However, drivers may also be interested in binds to higher level devices (e.g. tunnel drivers) to potentially offload filters applied to them. Introduce indirect block devs which allows drivers to register callbacks for block binds on other devices. The callback is triggered when the device is bound to a block, allowing the driver to register for rules applied to that block using already available functions. Freeing an indirect block callback will trigger an unbind event (if necessary) to direct the driver to remove any offloaded rules and unreg any block rule callbacks. It is the responsibility of the implementing driver to clean any registered indirect block callbacks before exiting, if the block it still active at such a time. Allow registering an indirect block dev callback for a device that is already bound to a block. In this case (if it is an ingress block), register and also trigger the callback meaning that any already installed rules can be replayed to the calling driver. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: add macros for PHYID matching in PHY driver config Add macros for PHYID matching to be used in PHY driver configs. By using these macros some boilerplate code can be avoided. Use them initially in the Realtek PHY drivers. ==================== Signed-off-by: -
Heiner Kallweit authored
Use new macros for PHYID matching to avoid boilerplate code. Signed-off-by:
-
Heiner Kallweit authored
Add macros for PHYID matching to be used in PHY driver configs. By using these macros some boilerplate code can be avoided. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: further phylib simplifications after recent changes to the state machine After the recent changes to the state machine phylib can be further simplified (w/o having to make any assumptions). ==================== Signed-off-by: -
Heiner Kallweit authored
Now that phy_mac_interrupt() doesn't call phy_change() any longer it's called from phy_interrupt() only. Therefore phy_interrupt_is_valid() returns true always and the check can be removed. In case of PHY_HALTED phy_interrupt() bails out immediately, therefore the second check for PHY_HALTED including the call to phy_disable_interrupts() can be removed. Signed-off-by:
-
Heiner Kallweit authored
When using phy_mac_interrupt() the irq number is set to PHY_IGNORE_INTERRUPT, therefore phy_interrupt_is_valid() returns false. As a result phy_change() effectively just calls phy_trigger_machine() when called from phy_mac_interrupt() via phy_change_work(). So we can call phy_trigger_machine() from phy_mac_interrupt() directly and remove some now unneeded code. Signed-off-by:
-
Heiner Kallweit authored
State PHY_CHANGELINK isn't needed here, we can call the state machine directly. We just have to remove the check for phy_polling_mode() to make this work also in interrupt mode. Removing this check doesn't cause any overhead because when not polling the state machine is called only if required by some event. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt Flag PHY_HAS_INTERRUPT is used only here for this small check. I think using interrupts isn't possible if a driver defines neither config_intr nor ack_interrupts callback. So we can replace checking flag PHY_HAS_INTERRUPT with checking for these callbacks. This allows to remove this flag from all driver configs. v2: - add helper for check in patch 1 - remove PHY_HAS_INTERRUPT from all drivers, not only Realtek - remove flag PHY_HAS_INTERRUPT completely v3: - rebase patch 2 ==================== Signed-off-by: -
Heiner Kallweit authored
Now that flag PHY_HAS_INTERRUPT has been replaced with a check for callbacks config_intr and ack_interrupt, we can remove setting this flag from all driver configs. Last but not least remove flag PHY_HAS_INTERRUPT completely. Signed-off-by:
-
Heiner Kallweit authored
Flag PHY_HAS_INTERRUPT is used only here for this small check. I think using interrupts isn't possible if a driver defines neither config_intr nor ack_interrupts callback. So we can replace checking flag PHY_HAS_INTERRUPT with checking for these callbacks. Signed-off-by:
-
David S. Miller authored
Same change as made to sctp_intl_store_reasm(). To be fully correct, an iterator has an undefined value when something like skb_queue_walk() naturally terminates. This will actually matter when SKB queues are converted over to list_head. Formalize what this code ends up doing with the current implementation. Signed-off-by: -
David S. Miller authored
To be fully correct, an iterator has an undefined value when something like skb_queue_walk() naturally terminates. This will actually matter when SKB queues are converted over to list_head. Formalize what this code ends up doing with the current implementation. Signed-off-by: -
David S. Miller authored
Eliminate the assumption that SKBs and SKB list heads can be cast to eachother in SKB list handling code. This change also appears to fix a bug since the list->next pointer is sampled outside of holding the SKB queue lock. Signed-off-by: -
David S. Miller authored
Instead of direct SKB list pointer accesses. The loops in this function had to be rewritten to accommodate this more easily. The first loop iterates now over the target list in the outer loop, and triggers an mmc data operation when the per-operation limits are hit. Then after the loops, if we have any residue, we trigger the last and final operation. For the page aligned workaround, where we have to copy the read data back into the original list of SKBs, we use a two-tiered loop. The outer loop stays the same and iterates over pktlist, and then we have an inner loop which uses skb_peek_next(). The break logic has been simplified because we know that the aggregate length of the SKBs in the source and destination lists are the same. This change also ends up fixing a bug, having to do with the maintainance of the seg_sz variable and how it drove the outermost loop. It begins as: seg_sz = target_list->qlen; ie. the number of packets in the target_list queue. The loop structure was then: while (seq_sz) { ... while (not at end of target_list) { ... sg_cnt++ ... } ... seg_sz -= sg_cnt; The assumption built into that last statement is that sg_cnt counts how many packets from target_list have been fully processed by the inner loop. But this not true. If we hit one of the limits, such as the max segment size or the max request size, we will break and copy a partial packet then contine back up to the top of the outermost loop. With the new loops we don't have this problem as we don't guard the loop exit with a packet count, but instead use the progression of the pkt_next SKB through the list to the end. The general structure is: sg_cnt = 0; skb_queue_walk(target_list, pkt_next) { pkt_offset = 0; ... sg_cnt++; ... while (pkt_offset < pkt_next->len) { pkt_offset += sg_data_size; if (queued up max per request) mmc_submit_one(); } } if (sg_cnt) mmc_submit_one(); The variables that maintain where we are in the MMC command state such as req_sz, sg_cnt, and sgl are reset when we emit one of these full sized requests. Signed-off-by:
-
- 10 Nov, 2018 3 commits
-
-
Michał Mirosław authored
It turns out I missed one VLAN_TAG_PRESENT in OVS code while rebasing. This fixes it. Fixes: 9df46aef ("OVS: remove use of VLAN_TAG_PRESENT") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
David S. Miller authored
The following: skb = skb->next; ... if (skb == (struct sk_buff *)queue) is transformed into: skb = skb_peek_next(skb, queue); ... if (!skb) Signed-off-by: -
Kyle Roeschley authored
The phy core provides a handy phy_speed_to_str() helper, so use that instead of doing our own formatting of the different known link speeds. To do this, increase PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE to 11 so we can fit 'Unsupported' if necessary. Signed-off-by:
Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by:
-
