On 2018-10-10 13:09, Vinod wrote: > On 10-10-18, 12:44, Peter Ujfalusi wrote: >> >> >> On 2018-10-10 07:05, Vinod wrote: >>> On 24-09-18, 16:00, Peter Ujfalusi wrote: >>>> From: Grygorii Strashko <grygorii.strashko@xxxxxx> >>>> >>>> Certain users can not use right now the DMAengine API due to missing >>>> features in the core. Prime example is Networking. >>> >>> What are the features you have in mind? >> >> The two big ones are: >> 1. Support for out of order completion of descriptors (cookie management) >> >> This mostly concerns the DEV_TO_MEM. >> Currently we have dma_cookie_t (s32) to track which descriptor is >> completed, which one is issued and which one is pending. >> It is mandatory that descriptors are completed in the same order as they >> were issued. >> >> We need to have support for out of order completion of the issued >> descriptors and thus the s32 way of tracking is not working. >> >> We basically have three use cases needed to be supported: >> 1a: in order completion (currently supported by DMAengine) >> 1b: out of order completion in a channel, descriptors can complete in >> different order. >> 1c: out of order completion in a channel, the completion is ordered >> within 'classification type' of descriptors via the channel >> >> If we issue descriptors 1, 2, 3, 4, 5, 6, 7 >> >> We could receive back them >> 1a: 1, 2, 3, 4, 5, 6, 7 >> 1b: 4, 7, 2, 1, 3, 5, 6 >> >> in case of 1c we can classify descriptors when issuing: >> 1(c0), 2(c0), 3(c0), 4(c1), 5(c1), 6(c1), 7(c1) >> >> and we receive the back like: >> 4(c1), 5(c1), 1(c0), 2(c0), 6(c1), 3(c0), 7(c1) >> >> The descriptors are coming back in 'random' order, however they are in >> order within their classification. > > when you say classification you mean actual HW channels right, so to > support that why should the cookie be provided from the channel where > you schedule the descriptor for? No, it is not actual HW channel. There is a concept of flowID in CPPI5 (as well in CPPI4). Each flowID is addressing (triggering) the corresponding receive flow (rflow) configuration. FlowID == 0x3fff would use the default flow for the channel, which has the same ID as the rchan So, We have a receive channel (rchan10). We have the default rflow10 for it We have extra FlowID range reserved for the channel (rflow180-188) The rflow configuration describes what to do when a packet with the matching FlowID has been received: - from which ring the free descriptor should be used (fdq - free descriptor queue) - to which ring the packet should be put when the packet is completed (rq - receive queue) - it has more fine grained control, but let's not worry about them now. In case of 1c each rflow have unique pair of fdq and rq. We can classify a packet to go to fdqA, which is used by rflowA and it is going to return the packet to rqA. But it could be that all rflows are pointing to one rq. So packets from fdqA/B/C/.. for rflowA/B/C/... are all going to be pushed to one rq. The 1b case is when all rflow has been configured to use a single fdq, but push the completed packets to different rq. In this mode it is easy to support packet priority for example: The eth hardware will push high priority packets with lower FlowID and the SW is first empties the rq which is associated with the lower indexed rflow configuration. I was thinking of representing the rflows as 'channels' but then there will packets coming out from channels where we have not even placed an RX - we push RX to one 'channel' but it is coming back on another in random order. > >> The must supported one is 1b at the moment, 1c should be reasonably >> simple to add support for. > > so you are adding 1b in this patch? Well, in a way yes. This patch makes it possible to use 1b in networking, but w/o using any DMAengine API. I want to avoid mixed use (abuse) of DMAengine and custom API. > >> >> 2. NAPI support >> >> Via NAPI an RX looks something like this: >> - give the hardware bunch of descriptors to receive packets >> - when the first packet is received get notification >> - disable the interrupts >> - schedule NAPI >> - in the NAPI poll function read out the completed descriptors one by >> one, process them, then give back the descriptor (with new buffer) to >> the hardware. >> - after poll finished (no more packets or got the number of packets NAPI >> told us to read out) enable the interrupts and wait for packets to start >> to flow in. > > Can that not be done by using the interrupt/ack flags? I don't think so. By definition the callback is called to notify the client that the transaction is completed (the given descriptor). After this the DMAengine considers the cookie to be completed, right? In NAPI however the client is notified that there is something pending for reception (via irq), the client then disable the interrupt. net core will initiate the polling and the packets are taken out from the HW. It is not possible to issue the first packet w/ DMA_PREP_INTERRUPT the others with w/o it for example as we don't know how many packets are going to come and we are not even sure if the first issued packet is going to be the first to come back. It is more like a new dma_transaction_type than per descriptor flag. The channel must know that it is in this mode so when it get the interrupt that there is something pending for reception, it would just disable the interrupt and tell the client this. Then we need to somehow be able to poll read the packets out. Either one-by-one read or a looping within DMAengine/DMA driver and calling a client provided callback for each packet. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
