Bridging the C++/CLI layer is a marshalling effort, where managed state is converted to primitive types to marshal to the unmanaged layer, processed, and then marshalled back. Depending on your algorithm, (and pragmatics for "wrapping" that transition layer), it is best to keep the marshalling as bounded (small) as possible.
So, it depends on the problem: The simplest problem would be an interface that sends a little primitive data across the C++/CLI layer, process a LONG time, and then send a little data back (e.g., minimal marshalling overhead). If your algorithm requires more extensive interaction across the C++/CLI layer, it gets quite a lot more tricky.
The benefit of "All C#" or "All Managed" is (1) skipping this marshalling layer (which is overhead, and sometimes tedious depending on the work), and (2) run-time optimizations that the .NET engine can make for the specific computer on which the code is running (which you can't have with native C/C++, nor unmanaged code).
I agree with other comments in this thread that you should/must "test" it with your scenarios. A "big" C++/CLI layer with performance-sensitive transition is very hard to do, because of the "boxing/unboxing" that (automatically) occurs when you keep jumping between managed/unmanaged.
Finally, the ultimate performance difference between the hybrid "managed/unmanaged" design versus the "all-managed" design relates to the trade-offs between: Can the .NET engine make machine-specific optimizations of the .NET code (for example, taking advantages of machine-specific threads/cores/registers), greater than the "pure native" code (which is linked into the mixed-mode assembly) is able to process FAST by bypassing the .NET engine (which is an interpreter)?
True, well-written native code can "detect" processor threads, but typically cannot detect machine-specific registers (unless compiled for that target platform). In contrast, native code does not have the "overhead" of going through the .NET runtime, which is merely a virtual machine (that may be "accelerated" through Just-In-Time compiling of some logic to its specific underlying hardware).
Complicated problem. Sorry. IMHO, there are just no easy answers on this type of problem, if "performance sensitive" is your issue.