I have the following circuit with Ethernet switch that connect to quad magnetic, my layout engineer required me to swap for easier layout. Pay attention - the swap will be only in the magnetic side, not in the PHY side, I'm just changing from MDIP0 that route to TD0+ to TD3+ and etc... Is is possible? I'm of course change the output of the magnetic. This is picture from datasheet:
Edit: this is BGA magnetics HX5401NL magnetic output definitions reflect these changes accordingly! 
The swap will be only in the magnetic side, not in the PHY side, I'm just changing from MDIP0 that route to TD0+ to TD3+ and etc... Is is possible? Im of course change the output of the magnetic.
Yes, it's often possible.
First, if you have a separate Ethernet magnetics module connected to a discrete Ethernet jack, and the input and output are simultaneously swapped at the magnetics, as long as ultimately the "correct" signals are routed to the Ethernet jack, the circuit is unaffected. The Ethernet magnetics is a module with passive parts, inside it, there are four transformers and four common-mode chokes, meant for four differential pairs. The magnetics itself is just an array of 4 transformers and chokes, and it doesn't care about which one is connected to which differential pair. Essentially, it's no different (ignoring the small difference in parasitic mutual inductance between the cores) from using 4 separate one-pair magnetics, it's up to you to decide which core is hooked up to which signal. If the inputs and outputs are changed simultaneously, it's legal to do without any consequence as the circuit is electrically identical. (unless the magnetics does something unusual, but that will be reflected in its datasheet).
Furthermore, even if only the input or output side is swapped, and ultimately the "wrong" signals are routed to the Ethernet jack - this is a common case if an Ethernet jack with an integrated magnetics is used (MagJack) that doesn't give you control at the output side - It's still often permissible due to pin mirroring, polarity reversal, and crossover detection supported by most Ethernet PHYs.
In PCB layouts, when a chip has the pinout 1, 2, 3, 4, 5, but another chip (or magnetics, or jack) has the pinout 5, 4, 3, 2, 1, the situation forces one to use a large number of vias. The pin mapping features in Ethernet PHYs are the solution to this problem, they change the pin definition of the Ethernet PHYs on the fly, simplify signal routing. Because the actual signal definitions are changed if these flipping/mirroring/swapping modes are enabled, these PCB routing changes must be back-annotated to the schematics.
7.4.6.5 Mirror Mode
In some multiport applications, RJ-45 ports may be mirrored relative to one another. This mirroring can require crossing board traces. The DP83867 can resolve this issue by implementing mirroring of the ports inside the device.
In 10/100 operation, the mapping of the port mirroring is:
- MDI: A → D, B → C
- MDIX: A → D B → C
In Gigabit operation, the mapping of the port mirroring is:
- MDI or MDIX: A → D, B → C, C → B, D → A
Mirror mode can be enabled through strap or through register configuration using the Port Mirror Enable bit in the CFG4 register (address 0x0031).
In Mirror mode, the polarity of the signals is also reversed.
These three features often can even be used in combinations. As a result, the MDI signals from Ethernet PHYs can be connected in many possible ways. One can select the option with the simplest routing.
However, before doing so you must study your Ethernet PHY datasheet carefully and make sure that:
You've already got an answer from @比尔盖子 who seems better informed than I am. Perhaps the extent of flexibility is actually down to specific implementations (chip models).
Historically I've been told (word of mouth) that at 1000Base-T, i.e. gigabit mode, the mating of pairs doesn't matter, as long as you don't swap individual wires out of pairs. I.e. pairs must remain pairs, is the only condition. But you can wire the pairs 1234 to 3142 no problem. The Gigabit mode runs full duplex per pair with echo cancelation, and can do the lane topology detection and training on its own / flexibly. Being the pedant that I am, I have never actually tested this - I always strive to crimp cables the way they should be, including the intended MDI vs. MDI-X. (It seems to make the link autoneg handshakes go faster.) I did not have enough motivation to try swapping the pairs deliberately. I actually had several occasions, where other people (oblivious of the color coding standard) crimped the wires wrong and mixed up the pairs, i.e. 3+4 5+6 :-) resulting in some funny situations. Honestly when crimping a cable, my major concern is not to confuse the white-colored wires among the pairs... mixing up the pairs on purpose doesn't seem entertaining.
Now at a more adult age, I've come to appreciate that there are nuances. The original NWay autonegotiation, later standardized as 802.3(u) clause 28, with the auto MDI/MDI-X enhancement, was firmly in the world of 10/100 Mbps Ethernet (no gigabit yet). It was all about the green and orange pairs, at pins 1+2 and 3+6 of the RJ45. I get it that swapping polarity and swapping pairs (not individual wires!) between orange and green pair is hereby okay - but, if the 802.3ab Gigabit Ethernet should work with any mapping of pairs, then the modern standard should make some arrangements for the clause 28 auto-negotiation bottom layer transport to permit any pair-wise mapping. Because auto-negotiation is mandatory for 1000Base-T. To check for such a standardized arrangement, I've skimmed the 2000 edition of 802.3. While it does standardize gigabit Ethernet, curiously to me, neither its updated clause 28, nor the gigabit-related enhancements in clause 40.5.1, nor the Addendum 28D, mention any free-style shenanigans with the pinout, for the purposes of auto-negotiation. The "modern" clause 40.5.1 of the gigabit era, simply refers to clause 28 for the principal "frugal transport layer of auto-negotiation" (FLP bursts). Then again I may be missing something - the whole spec is 1500 pages in the 2000 edition.
Like I could imagine the auto-MDI-MDI/X to be sort of extended, say "transmit your FLP bursts in turns at the orange and green pairs, but listen for them at all 4 pairs, and upon detecting an FLP burst from the other party, adjust the mapping accordingly". Which would work for gigabit-to-gigabit, but not necessarily for backward compatibility with 100Base-TX (only) compliant peers. Maybe try transmitting your FLP bursts and ACKs on all four pairs as well? And once you get an ACK in addition to the RX FLP burst, you know the correct TX pair. Again I haven't found this in the standard.
So, unless you can actually configure the PHY using pin-straps or EEPROM (soft straps) for a particular ordering of the pairs, I would suggest to adhere to MDI or MDI-X with the green and orange pairs, in your board routing. So that the basic auto-nego layer works. Once the parties agree on 1000Base-T, they can possibly sort out the other two pairs at the link training stage, or something (not sure this is a relevant train of thought).
Tangential closing notes and anecdotes:
The standard strictly says that the auto-negotiation transport relies on the FLP bursts, which themselves are derived from the 10 Mb NLP pulses. It requires (an element of?) 10Mb transmission capability. Now - at board level I've seen Ethernet ports, supporting either 100/1000 only (gigabit PHY technology) or 100/1G/10G (multi-rate 10GBase-T). It's true that the former example is possibly limited in software (as far as the PHY is concerned) and really runs with 10Mb-capable magnetics and line transceivers - the exclusion of 10Mb may have to do with the PTP capability of that particular board, implemented in an FPGA, where implementing 10Mb would possibly mean added complexity / sub-prime timing accuracy / eat valuable FPGA real estate for a dubious purpose (or something). But how about those 10GBase-T ports? The 802.3 standard does say that only the "10Mb FLP Burst" capability is required (for auto-negotiation purposes), while actual 10Base-T mode for payload data need not be implemented and advertiesed. Perhaps that's how auto-negotiation is satisfied in 10GBase-T ports without nominal 10Mb backward compatibility.
I've actually seen ill HW constellations, where two gigabit NIC's only had the orange and green pair wired among themselves (no blue and no brown). On different occations, I've seen two different outcomes:
A) while the initial stages of the clause 28 handshake would work, the link would never start to transfer payload data, because the pairwise training for gigabit fails.
B) the link ultimately comes up, after a couple dozen seconds of failed attempts to train for gigabit - comes up in 100 Mb mode.
I.e. for B) to work, one of the parties must back away from its gigabit ambitions and probably re-advertise 100Mb only, or something along those lines. This behavior could possibly be implemented in a software driver.
A couple years ago, I have cobbled together a semi-passive eavesdropping tap for 100Mb Ethernet: passive for signal timing, but with active differential repeaters into the tap outputs, and perfectly impedance-matched. Takes two NIC ports for the listening/recording part, one for each direction. When recording traffic using T-shark or Wireshark, I have noticed that in different recording sessions, I can't seem to get the directions "fixed", from ports on the physical eavesdropping splitter, to my listening NICs. Wireshark coloring rules pointing in a different direction in each capture session. Just can't seem to put my finger on the correct indexing. Then it hit me: auto MDI/MDI-X at both ends. The resulting pairwise direction was completely random after every "link up" :-) Making the exercise slightly more tangled if the recording session contained events of "link lost and re-acquired".
