On Sat, Jan 11, 2014 at 08:48:12AM +1000, Peter Crosthwaite wrote: > On Mon, Jan 6, 2014 at 4:12 PM, Stefan Hajnoczi <stefa...@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 <stefa...@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.galv...@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. Or possibly nr 2, not sure if I understood that one correctly though. Cheers, Edgar
