On Sun, Jan 12, 2014 at 11:59 PM, Edgar E. Iglesias <edgar.igles...@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 <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.
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 >
