Hi Sinan

>    If hardware doesn't support it, blacklisting should have been the right
>    path and I still think that you should remove all switch business from the 
> code.
>    I did not hear enough justification for having a switch requirement
>    for P2P.
  
We disagree. As does the community based on feedback on previous version of 
this patch set.
  
> You are also saying that root ports have issues not because of functionality 
> but
> because of performance. 

I have seen both.  Some systems fail in entirety to route TLPs across route 
ports. Others do route but with poor performance. Having a requirement for a 
switch is therefore a reasonable and sensible minimum criteria for enabling p2p.
    
> If you know what is bad, create a list and keep adding it. You can't assume
> universally that all root ports are broken/ have bad performance.

I actually wanted to do a blacklist originally but that idea was not accepted 
by the community. 
    
>    What if I come up with a very cheap/crappy switch (something like used in 
> data
>    mining)?
> What guarantees that P2P will work with this device? You are making an
> assumption here that all switches have good performance.

A switch must support P2P or it is in violation of the PCIe specification.
    
>    I have been doing my best to provide feedback. It feels like you are 
> throwing
>    them over the wall to be honest.

I think one issue Sinan is that a lot of your ideas have been discussed in 
previous versions of the series. So you are asking us to make changes which, in 
some cases, we know are not acceptable to others in the community. The input is 
welcome but it flies in the face of other input we have received. 

However if other developers feel strongly about the blacklist/whitelist and 
switch criteria please speak up! ;-)

Stephen

    

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to