Re: [Qemu-devel] [PATCH 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller

[Peter Crosthwaite <peter.crosthwaite@xilinx.com>]

On Sun, Jan 12, 2014 at 11:59 PM, Edgar E. Iglesias
<edgar.iglesias@gmail.com> wrote:
> On Sat, Jan 11, 2014 at 08:48:12AM +1000, Peter Crosthwaite wrote:
>> On Mon, Jan 6, 2014 at 4:12 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> > On Mon, Jan 06, 2014 at 01:46:54PM +1000, Peter Crosthwaite wrote:
>> >> On Mon, Jan 6, 2014 at 1:27 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> >> > On Thu, Jan 02, 2014 at 08:25:10PM +1000, Peter Crosthwaite wrote:
>> >> >> Hi Beniamino,
>> >> >>
>> >> >> On Thu, Jan 2, 2014 at 7:18 PM, Beniamino Galvani <b.galvani@gmail.com> wrote:
>> >> >> > This patch adds support for the Fast Ethernet MAC found on Allwinner
>> >> >> > SoCs, together with a basic emulation of Realtek RTL8201CP PHY.
>> >> >> >
>> >> >>
>> >> >> More a comment for net in general, but I think sooner or later we need
>> >> >> to move towards a split between phy and mac on the device level.
>> >> >> continuing the phy-within-mac philosophy is going to make the
>> >> >> socification efforts awkward. Are MII and friends a busses (as in
>> >> >> TYPE_BUS) in their own right, and connection of mac and phy has to
>> >> >> happen on the board level?
>> >> >
>> >> > I see PHY and MAC split as advantageous because it allows code reuse and
>> >> > better testing.  The main thing I'd like to see is PHY device tests
>> >> > using tests/libqtest.h.
>> >> >
>> >> > If someone wants to implement it, great.  It would make it easier to add
>> >> > more NIC models in the future.
>> >> >
>> >> > Regarding SOCification and busses, I'm not sure.  Is it okay to just say
>> >> > a NIC has-a PHY (i.e. composition)?
>> >> >
>> >>
>> >> Generally speaking, in the (ARM) SoCification the MAC is part of the
>> >> SoC which in the latest styling guidelines is a composite device. This
>> >> composite is supposed to reflect the self contained SoC product which
>> >> the PHY is usually not a part of. So we have two opposing compositions
>> >> here:
>> >>
>> >> NIC = MAC + PHY
>> >> SOC = CPUs + MAC + ...
>> >>
>> >> MAC can't be in both. So for SoCs the NIC concept needs to abandoned.
>> >> After all the expansion of NIC as "Network Interface Card" is a little
>> >> bit PCish. Your average SoC networking solution has no such "card".
>> >> Just an on chip MAC (same pacakge/die as CPU etc) connecting to a PHY
>> >> via PCB traces.
>> >>
>> >> So I think long term, MII has to be a TYPE_BUS that is visible on the
>> >> top level SoC device. Self contained NICs (as we know them today) are
>> >> then also implementable as container devices (of MAC and PHY) that use
>> >> this bus internally (in much the same way the SoC boards would attach
>> >> external PHY to SoC).
>> >
>> > Okay, that makes sense.  Given the amount of emulated hardware in QEMU
>> > today, I think it would be okay to simply add new MAC/PHYs while still
>> > supporting the NICs of old.  If someone is enthusiastic about
>> > refactoring and testing existing NICs then great.  But I think it's more
>> > pragmatic to simply start working with a split MAC/PHY where that is
>> > beneficial.
>> >
>>
>> Alright,
>>
>> So lets make some plans. There is devil in the detail here. There was
>> a previous attempt to do something similar by Grant early last year so
>> cc as FYI.
>>
>> So the main question is whether or not this new interface is just for
>> MDIO or is the full MII interface (both MDIO and packet data).
>>
>> My inclination is the latter, we want a new proper QOM bus that is
>> both. What this would mean, is that these MAC-only devices wont be net
>> devices at all. the -net args are instead applied to the PHY. This
>> makes the most sense to me as its the phy that actually has copper
>> connection to the external network, not MAC.
>>
>> MAC <---- TYPE_MII_BUS ----> PHY <-----net layer ------> external
>> network: "-net foo,bar,baz"
>
> I don't really agree with this. You can do ethernet without a PHY,
> it is in fact fairly common in the embedded switch space. You can also
> have a single MDIO iface that is completely separate from any MAC take
> care of many PHYs.
>
> IMO, the MDIO bus should be separate from the data path.
>
>
>> Another approach is to make both net devices in their own right. Phy
>> has two net-layer-managed attachments, one for external network, and
>> one point-to-point for the MII connecting to MAC. The MDIO bus is then
>> a side channel which may or may not be QOMified (depending on effort
>> levels). So you can still connect a standalone MAC to an external
>> network, assuming the guest can handle no PHY (may in reality have
>> limited use).
>>
>> MAC <---- net layer --------> PHY <-----net layer ------> external network
>>     <---- TYPE_MDIO_BUS ---->
>>
>> OR:
>>
>> MAC <---- net layer --------> external network
>>
>>
>> The third approach (which is closest to current implementation) is to
>> only have the phy do MDIO and still connect the MAC straight to an
>> external network:
>>
>> MAC <---- net layer --------> external network
>>      \
>>       <-- TYPE_MDIO_BUS ----> PHY
>>
>> I dont like this though, as its a little mismatched to real hw.
>> Although it may be a good stepping stone to approaches 1 or 2.
>
> I'd go for this third one and possibly do something about the
> data path later if needed.

Yeh, so I think that really translates to do option 3 and go to option
2 later if needed. So option 3 looks to be the winning plan for the
first series.

> Or possibly nr 2, not sure if I understood
> that one correctly though.
>

Option 2 is is the hardest but does solve your problem of either MAC
or PHY connecting to a network and with a more accurate data flow
model. I think you want to do 3 first to get there. So we can plan 3
with consideration for 2.

Regards,
Peter

> Cheers,
> Edgar
>