Home Forum Software discussion 10G interfaces not working

This topic contains 19 replies, has 6 voices, and was last updated by  svena 1 month, 1 week ago.

Viewing 5 posts - 16 through 20 (of 20 total)
  • Author
    Posts
  • #7460

    teknoraver
    Participant

    Hi,

    I’m using the shipped Ubuntu image with a 5.1 kernel compiled by me. The patches are only needed to make it faster and enable XDP, you can find them on my github repository. This is the kernel config I used.

    #7546

    nanasi
    Participant
    #7577

    svena
    Participant

    Hi,

    I can shed some light on the 10GB port situation.
    The SFP ports should all work in newer Kernel 5.1 for example.
    The RJ45 10GB shared ports are not working in the Kernel.

    This is due to the PHY driver.
    It is missing some support for phylink and other things at the moment.
    There are some patches in Russell Kings branch here:
    http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=mcbin

    That should fix that but I have not tried them yet.

    #7578

    svena
    Participant

    Hi teknoraver,

    your XDP patches are great.
    Do you know where your speedup is coming from?
    Are you utilizing XDP or has it something to do with the 32bit address allocation you added?

    #7582

    svena
    Participant

    Btw for the detection of the SFP modules you need to enable the mac link interrupt.
    An interface down and up also detects it but no changes to the modules:

    From ec4433deddce81a47690cfcf0e3c82e3d2452621 Mon Sep 17 00:00:00 2001
    From: Russell King <rmk+kernel@armlinux.org.uk>
    Date: Fri, 9 Nov 2018 19:26:56 +0000
    Subject: net: marvell: mvpp2: phylink requires the link interrupt
    
    phylink requires the MAC to report when its link status changes when
    operating in inband modes.  Failure to report link status changes
    means that phylink has no idea when the link events happen, which
    results in either the network interface's carrier remaining up or
    remaining permanently down.
    
    For example, with a fiber module, if the interface is brought up and
    link is initially established, taking the link down at the far end
    will cut the optical power.  The SFP module's LOS asserts, we
    deactivate the link, and the network interface reports no carrier.
    
    When the far end is brought back up, the SFP module's LOS deasserts,
    but the MAC may be slower to establish link.  If this happens (which
    in my tests is a certainty) then phylink never hears that the MAC
    has established link with the far end, and the network interface is
    stuck reporting no carrier.  This means the interface is
    non-functional.
    
    Avoiding the link interrupt when we have phylink is basically not
    an option, so remove the !port->phylink from the test.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    ---
     drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
    +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
    @@ -3447,7 +3447,7 @@
     		valid = true;
     	}
     
    -	if (priv->hw_version == MVPP22 && port->link_irq && !port->phylink) {
    +	if (priv->hw_version == MVPP22 && port->link_irq) {
     		err = request_irq(port->link_irq, mvpp2_link_status_isr, 0,
     				  dev->name, port);
     		if (err) {
    
Viewing 5 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic.

Technical specification tables can not be displayed on mobile. Please view on desktop