lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Nov 2008 01:09:09 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Miguel Ángel Álvarez <gotzoncabanes@...il.com>
Cc:	netdev@...r.kernel.org, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: ixp4xx_hss MAX_CHAN_DEVICES

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

> I think I do not make me understand myself... The question is: Do you
> know which message should I send to the NPE to configure it for MVIP
> mode?

You mean the low-level messages to NPE-A?

First you need to set the frame length (max is 1024 bits)
and fill the LUT (the slot mapping table) correctly (max 128 slots).

If I understand and remember this correctly, for HDLC you need to send
PKT_NUM_PIPES_WRITE = 4 (or 2 for 2E1), and I think
PKT_PIPE_FIFO_SIZEW_WRITE must be reduced (to 1 for 4 HDLC pipes and
2 for 2 pipes?).

For channelized mode you need CHAN_NUM_CHANS_WRITE (0 - 128, number of
active channels only).

Basically MVIP divides your entire frame into 2 or 4 parts.

> - If you have just one source of data, you can use packetized mode
> (and it does not care which clock rate you are using...).
> - If you have more than one sources of data and are working (for
> example) with an E1, you create a channel for each source, and the
> driver manages it.
> - But... If I want four sources of unstructured data (one for each
> "E1" in a 4E1), must I use a channelized mode, or a packetized mode?

These are unrelated.

a) all four E1s in 4E1 are completely independent. Their packetized
streams are, thus, independent as well. You may think about them as of
four (almost) separate physical interfaces. I think the NPE can do a
single HDLC stream over a 1024-bit frame, but this isn't technically
MVIP, it's a single logical interface with data rate up to 8 Mb/s.

b) packetized mode is mostly for HDLC. You need it if you want to have
Frame-Relay, X.25, Cisco HDLC, synchronous PPP etc. over some
channels (timeslots) (partial E1/T1 etc) or over the full frame (all
channels). The chip has only one HDLC controller per logical interface
(E1 etc) so you can only have one HDLC stream per (member of MVIP) E1.

If you need multiple streams of packets (per logical interface), you
can use Frame-Relay with multiple PVCs, or, for example,
Ethernet-alike VLANs.

c) Channelized mode is for bit-transparent data - mainly voice
communications (circuit-switched, e.g. ISDN with 64 kb/s per channel),
or when you don't care what's being transmitted because you are only
forwarding the traffic (and not terminating it with e.g. HDLC).



You can have both channelized and packetized timeslots on your
interfaces (logical and physical). For purely packetized data ("full"
physical interface used by a single HDLC stream) you don't even need a
framer, because you don't care when the frame starts, or if there is
frame at all. Otherwise, you need a framer (for a single E1/(T1) there
is an experimental software framer, for MVIP you need a hardware
chip).


The clock is yet another thing independent of the above. If you
connect a DCE to the HSS, the DCE will usually provide the clock. The
(hardware) framers and/or E1/T1 transceivers will do as well.
The internal clock is usually needed when the HSS acts as DCE itself,
usually when you connect two similar devices together (two DTEs).
That's why it's currently fixed at 2 Mb/s, it's mostly for tests.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ