On 13/03/18 05:19 PM, Sinan Kaya wrote: > It is still a switch it can move packets but, maybe it can move data at > 100kbps speed. As Stephen pointed out, it's a requirement of the PCIe spec that a switch supports P2P. If you want to sell a switch that does P2P with bad performance then that's on you to deal with. > What prevents that switch from trying P2P and having a bad user experience? The fact that no one would buy such a switch as it would have a bad user experience with regular PCI transfers. A P2P TLP is not special on a switch as it's routed in just the same way as any others. There'd also be no cost gain in making such a broken-by-design device. > If everything is so broken, I was suggesting to at least list the switches > you have tested. > > What's the problem with this? More complexity for zero gain. > Why do you want to assume that all switches are good and all root ports are > bad? Because the assumption that all switches are good is more than reasonable and simplifies the code and maintenance significantly. No one wants to maintain a white list when they don't have to. > What if the design is so canned that you can't change anything? Based on the feedback we've got so far and the developers that have participated in getting it to where it is, it is not "canned". > I have been asking things like getting rid of switch search in ACS > enablement towards achieving generic P2P. You seem to be pushing back. > You said yourself P2P and isolation doesn't go together at this point > but you also care about isolation for other devices that are not doing > P2P. P2P and isolation will never be compatible at any point. They are two opposite concepts. So we could just disable isolation across the whole system and for our purposes that would be fine. But it's relatively simple to limit this and only disable it behind switches. So why wouldn't we? It enables use cases like having an isolated card on the root complex used in a VM while having P2P on cards behind switches. I personally have no interest in doing this but I also have no reason to prevent it with my code. > It is not a requirement for you but it is a requirement for me (ARM64 guy). > Linux happens to run on multiple architectures. One exception invalidates your > point. It is not a requirement of an architecture or people that use a specific architecture. It is a requirement of the use-case and you have not said any use case or how we could do better. If you're running VMs that require isolation you will need to be *very* careful if you also want to do P2P between cards which requires no isolation. But, based on my understanding, most people will want to do one or the other -- not both. If you want to do P2P you enable the P2P config option, if you want isolation you don't. > If you are assuming that your kernel option should not be used by general > distributions like Ubuntu/redhat etc. and requires a kernel compilation, > creating a dependency to EXPERT is the right way to do. I don't have a problem adding EXPERT as a dependency. We can do that for v4. I'd rather hope that distros actually read and understand the kconfig help text before enabling an off-by-default option. But maybe I'm asking too much. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
