Re: ixp4xx_hss MAX_CHAN_DEVICES

[Krzysztof Halasa <khc@pm.waw.pl>]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

>> Basically MVIP divides your entire frame into 2 or 4 parts.
>>
> Sure. But... It is automatically activated when the frame length is
> greater than 256 or should it be explicitelly set?

You must set the number of (packetized) pipes.
For channelized data, there is apparently no difference.

> OK... I understand the concept, but I am not sure about how this is
> integrated with your driver (or the NPE). I mean... When I use your
> driver, I obtain two interfaces hdlc0 and hdlc1 (one per HSS). If I
> had only a packetized stream, I could open a socket to the interface
> and send the data. No problem (I think) in it.
> But if I want to have four streams (one per E1), is your driver
> prepare to deal with this, or should I manage to create four
> interfaces per HSS?

The driver is currently missing the MVIP code.

> In the first case... Is it related with set_hdlc_chan function? The
> name could suggest this, but then it does nothing for MODE_HDLC but
> MODE_RAW and MODE_G704.

That's for channelized data.

> In the second case... I understand that if I have to add the new
> interfaces, they should be network interfaces. Where do you recommend
> me to do it?

I'd have to look at it.

> In both cases... How can the user direct his data to one E1 or the other?

Each "member" E1 is connected to its respective HDLC controller
("packetized pipe"), and these have "TX" and "RX-free" queues (one set
per each HDLC).

> In my case (bad luck...) we have a legacy mode of connection, so I
> cannot use any of the methods described. I "just" need something
> similar to the IxHssAccPktPortConnection in the Intel Software
> Library...

Sure, you can use this raw HDLC + packet interface. One stream per
(member) E1/T1 (or, to be precise, one stream per 1, 1/2 or 1/4 of the
physical interface).
-- 
Krzysztof Halasa