Re: [PATCH RFC 5/6] net/faraday: Enable NCSI interface

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2015-11-10 at 17:12 +1100, Gavin Shan wrote:
> 
> > So we require the interface to be opened to talk, so far so good,
> > the NC-SI stack doesn't even need to open it itself, it's acceptable
> > to require userspace to do it. IE. Userspace will chose what interface
> > to use, open it (for DHCP etc... or whatever other reason) and *that*
> > will then trigger the NC-SI negociation.
> > 
> 
> Yes, NCSI is smiliar to PHY to some extent. However, PHY's negotiation
> is purly electrical procedure, no packets received from MAC for it. We
> have the same situation when the NCSI/PHY is going to be brought down.

Right but we similarily only support PHY nego once the driver is open,
at least on most drivers. The only difference really is that we only
set the netif_carrier_on() when the PHY detects a link, while for NC-SI 
we currently need to keep it on always or we lose the queues, but that
can be looked at separately.

> At the beginning, the NCSI packets can be received and transmitted after
> the interface is opened.

Right.

>  Before NCSI negotiation is done, no other packets
> can be received and transmitted.

The interface doesn't care. We can transmit them, they just may not go
anywhere, its not our problem. Similarily, the companion NIC may or may
not forward incoming packets before the nego is complete, we don't
actually have to care or enforce anything here.

>  For the Rx path (for other packets), the
> NCSI link isn't enabled when NCSI negotiation isn't finished. There might
> have lots of egress packets whose IP addresses can't be resolved to MAC
> address as ARP resolution doesn't work before NCSI negotiation is done.

Correct, but is that a problem ? it's the same thing when we don't have
a link, though I suppose we have a faster path to drop them when the
carrier is down.

> So there is a weird window: interface is up, but no packets (except NCSI
> packets) can be received or transmitted.

Right but that's similar to what we used to do before we had
"intelligent" PHY control... our drivers didn't always know when the
link was up or even if there was a cable plugged.

I agree, it would be nicer to have the "Carrier" follow the
establishment of the NC-SI link, and we should look into fixing that
separately, possibly by establishing a special queue discipline rather
than noop when in that "limbo" mode, but that shouldn't be a blocker
for the patches and certainly doesn't require your driver change that
deals with interrupts while the interface is closed.

> When the interface is brought down, for example by "ifconfig eth0 down",
> The NCSI interface needs to be teared down by transmitting and receiving
> NCSI commands and responses.

That can be done synchronously from the close callback (With timeouts),
can't it ? If the core messes around with our state before close is
called, then we need to do something in the netdev core. However, it's
probably fine to just not do anything, worst case the companion NIC
will forward packets to a closed interface. Not a big deal and
definitely not a show stopper.

>  Similiarly, it introduces another weird window:
> interface is down, but NCSI packets still can be transmitted and received.

No, when interface is down, it's down. Nothing comes in and out, we
free the rings, rx skb's, interrupt, it's all gone. We even power down
the NIC in most cases.

Ben.

> > Cheers,
> > Ben.
> > 
> 
> Thanks,
> Gavin
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html